[lldb-dev] ASan LLDB debugging extensions

[Enrico Granata]

Hi,
I have to say I am not so sure this API makes entirely sense on a ValueObject. I do see the rationale: use the ValueObject containing the pointer as the source of the pointer value to then look up.
However, it's entirely possible to craft VOs from scratch, so there is no additional guarantee that you will get a valid result back just because a VO claims to be a Foo* at 0x123! Given that it doesn't buy us anything, a VO is a pretty heavyweight tool and it seems you wouldn't use anything but an address out of it. So why not just use an address as input?

I think Jason has been working on a SystemRuntime component for this kind of "underlying execution environment, tell me things" behavior.
It might be a good design here to sync up with him and see if it makes sense to add these ASanInfo calls to the SR, possibly taking an lldb::addr_t (or an lldb_private::Address, if you feel you might need that kind of detailed info) instead of a ValueObject (since an address is what you really care about anyway, it makes everyone's life easier not having to trade in a complicated creature like a VO)

Sent from my iPhone

> On 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/20140714/333e157a/attachment.html>