[LLVMdev] dwarf directory table and file table

[Devang Patel]

On Aug 3, 2011, at 1:37 PM, Nick Lewycky wrote:

> On 2 August 2011 20:02, Devang Patel <dpatel at apple.com> wrote:
> Hi Nick,
> 
> On Aug 2, 2011, at 6:56 PM, Nick Lewycky wrote:
> 
> > I've been looking into the debug info in llvm recently. After conferring with a DWARF expert, I think what we really want for a file is to enter the actual name of the header that the preprocessor found between "" or <> on the #include line, and for the directory it should be the actual header search path used.
> 
> There are few wrinkles here, because these are preprocessor tokens.
> 
> Sure, but I was thinking of nabbing the actual string after macro expansion. Clang's PresumedLoc.getIncludedLoc() points to the post-macro expansion buffer.
>  
> - What about #include_next ?
> - #include <Foo/Foo.h> does not mean  {include path ...}/Foo/Foo.h for Apple's framework header.
> - Some IDEs, like Xcode, uses header maps. If you're curious search HeaderMaps in clang FE.
> 
> The dwarf line table should be able to encode directory names. I am not sure, what is the advantage of using actual tokens between "" or <> as a file name ?
> 
> The DWARF committee's intent is that line table faithfully represent the user inputs which led the compiler to doing what it did. You brought up excellent points of course and I think they should be brought up with the DWARF committee.
> 
> For now I think we can largely ignore these issues; #include_next could be implemented by equivalence to "#include <whatever included the outer header>",

> frameworks could be treated as-if they had their equivalent -I lines written out,

#include <Cocoa/Cocoa.h> means include /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h. As you see, there is no substring in actual path that matches user input.

> and HeaderMaps are ... odd, but we can probably figure something out (what do they currently do?).

HeaderMap short circuits compiler's include header search; in other words, it tells compiler to ignore all include paths and use file on disk directly pointed by the map.

Using HeaederMaps, IDE can instruct compiler to include /I/am/really/here/MyHeader.h when it sees #include <a/b/c.h>

-
Devang

> 
> BTW, I do not know of any assembler directives like .directory
> 
> Thanks, though I'm rather surprised. I guess then this is where I'll need to start, with an extension to the assembly directives. (Wish me luck!)
> 
> Nick
> 
> > I started by taking a look at how LLVM encodes this in a .s file and got pretty confused pretty quickly. For starters, we don't seem to ever emit any data directly into the .debug_line section directly. Is it filled in by the assembler based on the .file and .line directives? It seems like the assembler doesn't actually offer independent control of the directory and the file names? I guess I could invent new assembly directives, but it seems pretty surprising that I would need to! Have I gotten myself on the wrong track?
> >
> > Nick
> >
> 
> -
> Devang
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110803/cdbfa993/attachment.html>