(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.bre...@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@cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
