[PATCH] Allow overriding -split-dwarf-file

[Lubos Lunak]

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. 
when I could use a compiler option that just sets one dwarf info field, if 
only I actually could use it.

 If you want a precedent, there's already -fdebug-compilation-dir, which 
AFAICT is exactly the same, just with a different dwarf info field.

> >> I could do with
> >> changing DW_AT_GNU_dwo_name explicitly after the build, but that seems
> >> needlessly complex given that this seems to be exactly what the option
> >> does. I don't see why I would be allowed to override any option except
> >> for this one.
> >
> > -Xclang and the underlying driver arguments aren't really a
> > stable/guaranteed interface. I'd be more inclined to accept this
> > change if it were just for some debugging, but since it sounds like
> > you want to rely on it, it's good for us to understand the goal and
> > perhaps suggest or provide the best way of achieving it long-term.

 It's stable/guaranteed enough for me, and I'd rather have a clean solution 
that maybe breaks one day than something hackish the whole time.

-- 
 Lubos Lunak