[LLVMdev] DebugInfo library

[Benjamin Kramer]

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.

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.

- Ben