[lldb-dev] Fwd: ASan LLDB debugging extensions

Doug Snyder dsnyder at blueshiftinc.com
Wed Oct 29 14:09:36 PDT 2014


(resend to include lldb-dev)


i don't know if you are the person to ask, but git says you wrote
TestMemoryHistory.py, so i thought i'd start with you.

when i run unit test TestMemoryHistory.py on OSX, the unit test won't
compile/link and complains that libclang_rt.asan_osx_dynamic.dylib can't be
found

if i remove "-fsanitize=address " (added from the Makefile in that
directory) from the compile/link, the unit test builds fine

is there something i need to do to make this unit test work on OSX?

were you able to get this unit test to build on OSX?



On Mon, Jul 14, 2014 at 6:24 PM, Kuba Břečka <kuba.brecka at gmail.com> wrote:

> 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
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20141029/4a706cc6/attachment.html>


More information about the lldb-dev mailing list