On Fri, Apr 4, 2014 at 9:07 AM, Lubos Lunak <[email protected]> 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 <[email protected]> wrote: >> > On Fri, Apr 4, 2014 at 8:24 AM, Lubos Lunak <[email protected]> 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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
