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>
Rafael Ávila de Espíndola
2011-Aug-03 02:16 UTC
[LLVMdev] dwarf directory table and file table
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?> NickCheers, 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>