<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi,</div><div>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.</div><div>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?</div><div><br></div><div>I think Jason has been working on a SystemRuntime component for this kind of "underlying execution environment, tell me things" behavior.</div><div>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)<br><br>Sent from my iPhone</div><div><br>On Jul 14, 2014, at 6:24 PM, Kuba Břečka <<a href="mailto:kuba.brecka@gmail.com">kuba.brecka@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div>Hi, </div><div><br></div><div>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 (<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074656.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-July/074656.html</a>), which should enable the debugger to query various additional information the runtime can provide. Basically this means:</div>
<div><br></div><div>* 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.</div><div><br></div><div>* shadow mapping information - these say how exactly is a memory address mapped into the shadow memory and back.</div>
<div><br></div><div>* 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.</div>
<div><br></div><div>* 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").</div><div><br>
</div><div>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:</div>
<div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre"> </span>ThreadList &</div><div><span class="" style="white-space:pre"> </span>ValueObject::GetStackTraces() { ... }</div>
<div><br></div><div>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.</div>
<div><br></div><div>The goal is to have ASan-aware LLDB commands, such as:</div><div><br></div><div><span class="" style="white-space:pre"> </span>(lldb) expr -x 0xf00f00</div><div><span class="" style="white-space:pre"> </span>// prints out the value of the expression, and if it's a pointer also</div>
<div><span class="" style="white-space:pre"> </span>// prints the malloc and free stack traces</div><div><span class="" style="white-space:pre"> </span>(lldb) memory read --shadow 0xf00f00</div><div><span class="" style="white-space:pre"> </span>// prints out the corresponding shadow memory instead</div>
<div><span class="" style="white-space:pre"> </span>(lldb) memory locate 0xf00f00</div><div><span class="" style="white-space:pre"> </span>// says it's a stack variable with name "foo", size, starting address</div>
<div><br></div><div>I'll send patch(es) shortly, but do you have any comments/hints on the idea in general?</div><div><br></div><div>Thanks,</div><div>Kuba</div><div><br></div></div>
</blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>lldb-dev mailing list</span><br><span><a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a></span><br><span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a></span><br></div></blockquote></body></html>