<div class="gmail_quote">On 20 October 2011 09:33, Devang Patel <span dir="ltr"><<a href="mailto:dpatel@apple.com" target="_blank">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">
<div style="word-wrap:break-word"><br><div><div><div>On Oct 19, 2011, at 4:42 PM, Nick Lewycky wrote:</div><br><blockquote type="cite">This is a follow-up to the thread that started here:<div> <a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110725/125101.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110725/125101.html</a></div>
<div><br></div><div>Would anyone object to a flag "-fdwarf-compilation-dir=..." clang flag that would clobber the DW_AT_comp_dir setting?</div></blockquote><div><br></div></div>My first reaction is to resist such flag. It is most likely solving the wrong problem. IMO, DW_AT_comp_dir is something whose existence no compiler user needs to know.</div>
<div><div><br><blockquote type="cite"><div>This is a gcc compatibility issue for us as we're relying on our ability to control this part of the debug output by setting $PWD. A flag would also work for me.</div>
</blockquote><br></div></div><div>Can you elaborate ? What is exactly missing in clang's debug output today ? and how does it differ from gcc ? and why does it matter ?</div></div></blockquote><div><br></div><div>Gladly! The build doesn't happen on the machine where the debugging happens, so the path computed for AT_comp_dir is useless. More concretely, clang is producing a DW_AT_comp_dir which looks like this:</div>
<div><br></div><div><div> <60> DW_AT_comp_dir : /some/path/ac64e1e113026f77bb1834d0e3ad1410/thesource/</div></div><div><br></div><div>To understand why, you first need to know that we run builds on hermetic build machines. Everything is an upload to these machines, including the source to be built, the headers it requires, the system headers, the compiler and linker, etc. It's a content-addressable storage system, so the files are named by the md5sum's of their contents. That's where the "ac64e1e113026f77bb1834d0e3ad1410" came from.</div>
<div><br></div><div>When we build, we cache the .o produced and use its md5sum to determine whether we need to relink or already have the linked output. Because clang outputs its own md5sum in its .o files (because it outputs its path in DW_AT_comp_dir), a change to clang will always trigger a relink, even if nothing else about the .o file changed. But that's the smaller issue, it only means that clang will be slower than gcc for our users.</div>
<div><br></div><div>Much worse is that when I try to debug a clang-built binary, gdb will take DW_AT_comp_dir + DW_AT_name and create "/some/path/ac64e1e113026f77bb1834d0e3ad1410/thesource/llvm/lib/VMCore/Function.cpp" which of course doesn't exist on my system. This has got to be fixed.</div>
<div><br></div><div>To make this work with GCC, we run "PWD=/proc/self/cwd gcc ..." which causes gcc to put "/proc/self/cwd" in DW_AT_comp_dir. Yep, that means gdb opens "/proc/self/cwd/llvm/lib/VMCore/Function.cpp" which works fine because /proc/self/cwd is a kernel-provided symlink to the process' current directory, which will be /home/nlewycky/thesource/.</div>
<div><br></div><div>My proposal is that we'll pass "-fdwarf-compiler-dir=/proc/self/cwd" to clang. What won't work is passing "-fdwarf-compiler-dir=/home/nlewycky/thesource" because then we would get cache misses again.</div>
<div><br></div><div>(For more background on our build system, see <a href="http://google-engtools.blogspot.com/2011/09/build-in-cloud-distributing-build-steps.html" target="_blank">http://google-engtools.blogspot.com/2011/09/build-in-cloud-distributing-build-steps.html</a> .)</div>
<div><br></div><div>Nick</div><div><br></div></div>