<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 3, 2011, at 1:37 PM, Nick Lewycky wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On 2 August 2011 20:02, Devang Patel <span dir="ltr"><<a href="mailto:dpatel@apple.com">dpatel@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Nick,<br>
<div class="im"><br>
On Aug 2, 2011, at 6:56 PM, Nick Lewycky wrote:<br>
<br>
> 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.<br>
<br>
</div>There are few wrinkles here, because these are preprocessor tokens.<br></blockquote><div><br></div><div>Sure, but I was thinking of nabbing the actual string after macro expansion. Clang's PresumedLoc.getIncludedLoc() points to the post-macro expansion buffer.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">- What about #include_next ?<br>
- #include <Foo/Foo.h> does not mean {include path ...}/Foo/Foo.h for Apple's framework header.<br>
- Some IDEs, like Xcode, uses header maps. If you're curious search HeaderMaps in clang FE.<br>
<br>
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 ?</blockquote><div><br></div><div>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.</div>
<div><br></div><div>For now I think we can largely ignore these issues; #include_next could be implemented by equivalence to "#include <whatever included the outer header>", </div></div></blockquote><br><blockquote type="cite"><div class="gmail_quote"><div>frameworks could be treated as-if they had their equivalent -I lines written out,</div></div></blockquote><div><br></div><div><font class="Apple-style-span" face="Monaco">#include <Cocoa/Cocoa.h></font> means include <font class="Apple-style-span" face="Monaco">/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h</font>. As you see, there is no substring in actual path that matches user input.</div><br><blockquote type="cite"><div class="gmail_quote"><div> and HeaderMaps are ... odd, but we can probably figure something out (what do they currently do?).</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Using HeaederMaps, IDE can instruct compiler to include <span class="Apple-style-span" style="font-family: Monaco; ">/I/am/really/here/MyHeader.h </span>when it sees<font class="Apple-style-span" face="Monaco"> #include <a/b/c.h></font></div><div><br></div><div>-</div><div>Devang</div><br><blockquote type="cite"><div class="gmail_quote">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">BTW, I do not know of any assembler directives like .directory<br></blockquote><div><br></div><div>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!)</div>
<div><br></div><div>Nick</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> 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?<br>
><br>
> Nick<br>
><br>
<br>
</div>-<br>
<font color="#888888">Devang<br>
</font></blockquote></div><br>
</blockquote></div><br></body></html>