This adds an option -gsplit-dwarf=<arg>. LLVM can create .dwo files in the given directory
during the implicit ThinLTO link stage.
Details
Diff Detail
Event Timeline
I don't think requiring a new option is a great user interface. In existing use cases the location of the .dwo file matches the location of the output file. Why is this one different?
In implicit ThinLTO, the object files are only temporary.
Sort of similar to using -gsplit-dwarf when compiling straight to an
executable (without using -c): "clang++ x.cpp y.cpp -o a.out" - where
should the .dwo files go then? If they go where the .o files go, then
they'll be in /tmp/ and get deleted either when the ocmpiler ends after it
runs the linker, or perhaps at some uncertain point in the future when the
temp space is reclaimed.
(granted, I'm not suggesting we support that actual case - it's not
terribly common for anyone who'd actually need -gsplit-dwarf - but the
implicit ThinLTO case looks quite similar for demonstration purposes)
I think that the .dwo files generally go where the user-specified final output goes. So in your example they would go where a.out goes, not where the intermediate/temporary .o files go.
Being able to override that is fine, but being required to specify a directory in order to get fission in the first place is not.
The only data we have is that where .o files go, .dwo files go beside them.
How to generalize this to other situations isn't really obvious to me -
even for a.out (do you put all the .dwo files next to a.out? in the same
directory? if the names collide, where then? etc).
Interestingly GCC for "g++ foo.cpp" puts the foo.dwo file right where it
would go by default (next to foo.cpp, even though there's no foo.o). Oh,
LLVM does that too. Huh. I'm not sure that's a terribly helpful default to
extrapolate to ThinLTO for, though.
I prefer to have a dedicated directory to store all the .dwo files. As dblaikie said, all the .dwo files are temporary files. In addition, in order to differentiate the .dwo files generated by different link stage with the same .o, we need to add
some suffixes to the .dwo file. So for a file a.o, we may need to generate a .dwo named a._${number}_${random_string}.dwo, which is not neat. Furthermore, we need to dealing with archive files. In this case, we may need to generate
multiple .dwo files for a single archive files.
lib/Driver/ToolChains/CommonArgs.cpp | ||
---|---|---|
444 | Can we default this to a path alongside the output file as @probinson suggested? |
Makes the default value to /path/to/binary_dwo, when DWO_DIR is provided, make the path to DWO_DIR/path/to/binary_dwo
lib/Driver/ToolChains/CommonArgs.cpp | ||
---|---|---|
428 | Will do. |
I think that if I pass -gsplit-dwarf=/path/to/foo I would expect the dwo directory to be named /path/to/foo, not /path/to/foo/something_dwo.