[cfe-dev] controlling the value of DW_AT_comp_dir

[Nick Lewycky]

On 20 October 2011 09:33, Devang Patel <dpatel at apple.com> wrote:

>
> On Oct 19, 2011, at 4:42 PM, Nick Lewycky wrote:
>
> This is a follow-up to the thread that started here:
>
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110725/125101.html
>
> Would anyone object to a flag "-fdwarf-compilation-dir=..." clang flag that
> would clobber the DW_AT_comp_dir setting?
>
>
> 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.
>
> 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.
>
>
> 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 ?
>

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:

    <60>   DW_AT_comp_dir    :
/some/path/ac64e1e113026f77bb1834d0e3ad1410/thesource/

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.

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.

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.

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/.

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.

(For more background on our build system, see
http://google-engtools.blogspot.com/2011/09/build-in-cloud-distributing-build-steps.html.)

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111020/6812918e/attachment.html>