dwarf directory table and file table

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

dwarf directory table and file table

Nick Lewycky-2
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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: dwarf directory table and file table

Rafael Espíndola
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: dwarf directory table and file table

Devang Patel
In reply to this post by Nick Lewycky-2
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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: dwarf directory table and file table

Nick Lewycky-2
On 2 August 2011 20:02, Devang Patel <[hidden email]> 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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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



_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev