[LLVMdev] dwarf directory table and file table

[Nick Lewycky]

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, and HeaderMaps are ... odd, but we can probably figure
something out (what do they currently do?).

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/b557dced/attachment.html>