[lldb-dev] ASan LLDB debugging extensions

[Enrico Granata]

Sent from my iPhone

> On Jul 14, 2014, at 7:18 PM, jingham at apple.com wrote:
> 
> These would be API's on SBValue, not necessarily ValueObject.  

That's fine. I was mostly concerned about the internal layer. It just didn't seem to me that a ValueObject would be the guy to ask that kind of question to.

> The problem is that you have to hang them off something that the SB API's expose.  We aren't exposing the SystemRuntime to the SB API's.  For instance in the stuff Jason did for Queues, this just got hung off of threads.  I think in general the APIs will be clearer if we, like Jason did, we hang information off the objects they naturally belong to rather than expose to the SB layer "how we got them..."
> 
> So we could either do something like:
> 
> size_t
> SBProcess::GetNumHistoryFramesForAddress(SBAddress, const char *type);
> 
> size_t
> SBProcess::GetHistoryFrameAtIndexForAddress(SBAddress, const char *type, size_t idx);
> 
> 
> etc.  Then you would get the history list passing in the address each time.  That's kind of gross.  We could make this a little better by returning an SBThreadList (what we ain't got yet).

It would probably be easy to make an SBThreadList for that matter
Also, what do you mean by type here? malloc/free? We should probably if at all have an enum here to describe "memory management event" rather than a char*

In general, I don't hate this process-based scheme. Address spaces are a property of a process so it seems to fit neatly within a textbook description of memory management at the process level.

> Or we could hang it off of an address directly.  But we want this to be convenient for Xcode to use as well, and it deals mostly with SBValues, so making it grab out an address seems awkward.
> 

Not sure if it's exposed to SBValue but we do have a GetPointerValue() API on ValueObject that tends to do the right thing. But, again, I was more interested in why hanging the API off our internal ValueObject than the public SBValue.

> So since the SBValue is the thing that will have an allocation history, it seems reasonable to ask it directly.  If it was made up to point to a random address, and that address has ASAN history, I'm not sure why it would be wrong to return that.  

It wouldn't. My argument was more along the lines of "don't use a ValueObject just because you hope it won't ever contain a bogus address". Whatever source you use to acquire it (random number generators included) if you give a valid address, you should get valid info back.

> And if the address had no history it would be fine to say so.
> 

Yes, totally.

> Jim
> 
> 
>> On Jul 14, 2014, at 6:41 PM, Enrico Granata <egranata at apple.com> wrote:
>> 
>> 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
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>