[lldb-dev] ASan LLDB debugging extensions

[Doug Snyder]

is the install/build of compiler-rt a special step needed just for OSX?

i don't seem to need a special build of compiler-rt to get
TestMemoryHistory.py to compile on ubuntu.

also, http://lldb.llvm.org/build.html does not seem to list this as one of
the requirements needed to build lldb

since lldb does not appear to assume that asan is present, maybe the unit
test should be skipped if the asan library is not installed/present

doug






On Wed, Oct 29, 2014 at 2:31 PM, Kuba Brecka <kuba.brecka at gmail.com> wrote:

> http://compiler-rt.llvm.org
>
> You should check out its source into /projects/ and just build as usually.
>
> Kuba
>
> Sent from my iPhone
>
> On Oct 29, 2014, at 2:27 PM, Doug Snyder <dsnyder at blueshiftinc.com> wrote:
>
> what is "compiler-rt"?
>
>
>
>
> On Wed, Oct 29, 2014 at 2:21 PM, Kuba Brecka <kuba.brecka at gmail.com>
> wrote:
>
>> It's probably compiler-rt missing in the build of llvm/clang. Without it,
>> your built clang doesn't have ASan (doesn't understand -fsanitize=address).
>> Can you try building with compiler-rt?
>>
>> Kuba
>>
>>
>> On Wed, Oct 29, 2014 at 1:54 PM, Doug Snyder <dsnyder at blueshiftinc.com>
>> wrote:
>>
>>> 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/1541e699/attachment.html>