[PATCH] Allow overriding -split-dwarf-file

[Eric Christopher]

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

I'm guessing you mean that the actual output file name differs? I.e.
some sort of temporary cached file ala ccache that doesn't have the
same name as the file that you've just compiled? The directory ends up
being the same here (or can be set with, as you surmised
-fdebug-compilation-dir).

If so, I don't mind an option to set here necessarily, but would like
to see it plumbed through and not rely on Xclang options.

-eric