llvm dev - Aug 2011 - [LLVMdev] dwarf directory table and file table

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110802/2a1611ad/attachment.html>

On 2011-08-02 21:56, 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.
> 
> 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?
I have no idea what is the "correct" behavior for DWARF, but with gcc
4.5 I get:


     .file 1 "llvm/bar.h"
...
     .file 2 "test.c"


When bar.h was found with -I and the include was '#include
"bar.h"'. How
does gdb/llvm use this information?
> Nick
Cheers,
Rafael

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.

- 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 ? BTW, I do not know of any assembler directives like .directory
> 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

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>