[LLVMdev] DebugInfo library

[Dmitry Vyukov]

On Sat, May 5, 2012 at 10:01 PM, Benjamin Kramer
<benny.kra at googlemail.com>wrote:

>
> On 05.05.2012, at 17:52, Dmitry Vyukov wrote:
>
> > Hi,
> >
> > I would like to extend DebugInfo library for the purpose of using it in
> AddressSanitizer/ThreadSanitizer run-time libraries.
> >
> > Current interface is:
> >
> > class DILineInfo {
> >   const char *FileName;
> >   uint32_t Line;
> >   uint32_t Column;
> >   ...
> > };
> >
> > class DIContext {
> >   ...
> >   virtual DILineInfo getLineInfoForAddress(uint64_t address) = 0;
> > };
> >
> > First, I would like to get function name associated with the address.
> > Then, I would like to get inlined frames as well.
> > Then, I would like to be able to get the same info about global
> variables.
> > Finally, I would like to receive explicit failure indicator.
> >
> > I see the resulting interface along the lines of:
> >
> > class DILineInfo {
> >   const char *Name;
> >   const char *FileName;
> >   uint32_t Line;
> >   uint32_t Column;
> >   ...
> > };
> >
> > class DIContext {
> >   ...
> >   virtual bool getLineInfoForCode(uint64_t pc, SmallVector<DILineInfo>
> *res) = 0;
> >   virtual bool getLineInfoForData(uint64_t address, DILineInfo *res) = 0;
> > };
> >
> > Any comments/suggestions?
> >
>
>
> The public DebugInfo interface was designed around a very specific use
> case, extracting file/line/column triples from an object file, so not much
> thought went into it. However, the only user is llvm-objdump so you can be
> really free in redesigning and extending it.
>
> I'd like to keep the DWARF stuff an implementation detail so you'll likely
> end up with something like DIFunction, DIGlobalVariable, … which is then
> filled by the dwarf-implementation of DIContext. Some operations require
> traversing the DIE tree so it would be nice if the API only gives you what
> you ask for. Getting the File/Line/Column triple is a completely different
> operation in DWARF than fetching the function name, so it's better to keep
> it in separate objects.
>

Hi Ben,

I see the point of fetching only what user asks for. So it will require an
enum with flags, a user will pass a set of flags regarding what he wants,
and the function will return a set of flags describing what is actually
fetched.

How strong do you feel about splitting it to
DILineInfo/DIFunction/DIGlobalVariable?
How now I need only symbol name for both functions and global vars. I would
prefer to keep it simple for now.



One caveat of the DWARF parser in LLVM is that it doesn't understand
> relocations. This isn't a problem on OSX (it doesn't use them) and wasn't a
> problem on linux at the time I wrote it, but clang now emits DWARF that
> makes use of relocations so they have to be resolved before the buffers are
> passed to the DWARFContext. We should have the necessary stuff in LLVM's
> libObject, so it shouldn't be too hard.
>
>
I see. Perhaps it's already fixed in lldb, lldb should work with
llvm-generated binaries.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120506/dd45f90f/attachment.html>