[PATCH] Allow overriding -split-dwarf-file

[David Blaikie]

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)

> 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