[PATCH] Allow overriding -split-dwarf-file

[Lubos Lunak]

On Friday 02 of May 2014, David Blaikie wrote:
> On Fri, Apr 4, 2014 at 9:07 AM, Lubos Lunak <l.lunak at centrum.cz> wrote:
> > On Friday 04 of April 2014, David Blaikie wrote:
> >> Oops, re-add cfe-commits.
> >>
> >> On Fri, Apr 4, 2014 at 8:34 AM, David Blaikie <dblaikie at gmail.com> wrote:
> >> > On Fri, Apr 4, 2014 at 8:24 AM, Lubos Lunak <l.lunak at centrum.cz> wrote:
> >> >> On Friday 04 of April 2014, Eric Christopher wrote:
> >> >>> ... Why would you want to do this?
> >> >>
> >> >>  The compile itself happens in a chroot and the expected and actual
> >> >> output locations differ (and don't even exist in the other tree).
> >> >
> >> > In your scenario the .dwo is not side-by-side with the .o? Or are you
> >> > overriding the .o name as well in some way?
> >
> >  The scenario is distributed compiling with Icecream
> > (https://github.com/icecc/icecream). If you don't know it, think distcc,
> > except more sophisticated in some ways, one of them being that it ships
> > the compiler to the remote host and uses it in chroot (which avoids a
> > number of problems and allows cross-compiling).
> >
> >  Which means the actual compile run lacks a number of things, like the
> > source file itself (piped using stdin), the source file location, or the
> > expected output location. The result goes to a temporary .o file, which
> > is generally not a problem (I don't think the name of the .o file
> > matters), but with split dwarf the .dwo name gets hardcoded to this
> > random location in the .o file. For performance reasons there's a chroot
> > location per compiler, not per compile, so while I could temporarily
> > create the right location, I'm not exactly eager to write the code to do
> > that properly with all the locks etc.
>
> I'm not sure why that would require locks, etc. At least you could
> generate a safe temp directory and put the source file in that
> directory with its intended name - then you just have to correct for
> the directory, but not the file or dwo file names, right? (&
> -fdebug-compilation-dir is already there - but, yes, as pointed out it
> should be elevated to a driver option if it's being relied upon)
>
> Maybe this doesn't work for relative paths? (eg: "clang x/y.cpp" from
> directory 'z', but I don't recall how clang names the dwo file, the
> comp dir file, etc, in that case)

 It doesn't work for absolute paths.

$ clang++ -c -g -gsplit-dwarf a.cpp -o /somewhere/a.o
$ readelf -wi /somewhere/a.o | grep dwo_name
    <c>   DW_AT_GNU_dwo_name: (indirect string, offset: 0x0): /somewhere/a.dwo

 Now how should I get the correct path for the dwo file, without locks and 
whatnot, if the same node gets two such compile jobs at the same time (not 
very likely, but possible) and would therefore need to output two 
different .o files with the same path and filename?

-- 
 Lubos Lunak