[lldb-dev] ASan LLDB debugging extensions

[Kuba Břečka]

Hi,

I'm trying to create a better support for debugging ASan-enabled binaries
in LLDB. I already started by proposing some API into the ASan runtime
library (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074656.html),
which should enable the debugger to query various additional information
the runtime can provide. Basically this means:

* malloc/free traces - given a memory address, the ASan runtime can return
recorded stack trace(s) of how that chunk of memory was allocated and/or
freed.

* shadow mapping information - these say how exactly is a memory address
mapped into the shadow memory and back.

* locating a memory address - ASan tracks globals and stack variables, so
it can provide a name (and size) given such a memory address; for heap
addresses it can give out the starting address and size of that chunk.

* gathering report information - when ASan detects an error, the reporting
mechanism can provide additional information, e.g. what kind of bug was
found ("heap-use-after-free").

For the malloc/free stack traces, it seems the best way to add this feature
would be to extend the ValueObject class with a generic API to retrieve a
list of HistoryThread objects, with some additional enum/constant-string to
tell the type of individual threads. Something like:
 ThreadList &
ValueObject::GetStackTraces() { ... }

The API for this should be reusable for other libraries/tools, for example
malloc_history could provide a very similar information. Since I want this
to be available in the SB API as well, Python scripting seems not to be the
way to go.

The goal is to have ASan-aware LLDB commands, such as:

(lldb) expr -x 0xf00f00
// prints out the value of the expression, and if it's a pointer also
// prints the malloc and free stack traces
(lldb) memory read --shadow 0xf00f00
// prints out the corresponding shadow memory instead
(lldb) memory locate 0xf00f00
// says it's a stack variable with name "foo", size, starting address

I'll send patch(es) shortly, but do you have any comments/hints on the idea
in general?

Thanks,
Kuba
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140714/b7e507e1/attachment.html>