[lldb-dev] ASan LLDB debugging extensions

[Doug Snyder]

in the long run, that makes sense.

currently, i'm trying to figure out why TestMemoryHistory.py is not working
on Ubuntu.  I was trying to see how TestMemoryHistory.py functioned on OSX
for comparison.  for now, i may try to install compiler-rt on OSX, so that
unit test will compile on OSX

on Ubuntu, TestMemoryHistory.py is compiling and running, but does not seem
to be relaunching the process to insert its library.  the first "thread
list" after the initial "run" is reporting that the "stop reason =
breakpoint", not "stop reason = exec"

doug



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

> You're right. The test should be conditional, and only run if your
> compiler has ASan. There has been some recent discussion on lldb-commits
> with the same conclusion. If that failing/erroring test bothers you, send
> out a patch that just skips the test. I'm pretty sure it would get accepted
> as a temporary solution until I add the conditional skip.
>
> Kuba
>
> Sent from my iPhone
>
> On Oct 29, 2014, at 2:52 PM, Doug Snyder <dsnyder at blueshiftinc.com> wrote:
>
> 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/e13d4591/attachment.html>