Clang should always add a dsymutil step whenever debug information is
generated and the compiler is acting as the linker driver with
temporary object files.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
When you don’t pass any specific options to the linker, it’s going to generate a temporary lto.o file in /tmp and delete it after the link. When dsymutil will try to read that, it won't be there anymore. Unless I'm missing I don't think this is going to work. If it turns out I'm mistaken please add that situation as a test case.
@JDevlieghere you are right, I'm missing the change to how clang determines it needs to pass the linker the object file path. Update coming momentarily.
Are you thinking of the -Wl,-object_path_lto,path/foo-lto.o code in AddLLVM.cmake where dsymutil is invoked after clang finishes? I'm using the same code path as this patch in https://reviews.llvm.org/D84127 using an empty source file to force ContainsCompileOrAssembleAction() to be true and get dsymutil to be invoked. When clang manages both the per-arch links and the dsymutil, the temporary objects get unique names (e.g. -object_path_lto /var/folders/0s/8zdwsz0d1glcx6v1nc_nv5gw0000gn/T/cc-95f3fc.o) and stick around until after dsymutil is invoked.
clang/lib/Driver/Driver.cpp | ||
---|---|---|
2037 | This should fix the same issue as the workaround I was using in D84127. I'm not entirely convinced that this is all of it though. It seems strange to me that these two scripts produce different build products (aside from ret0.o): $ rm -rf external ret0 ret0.* $ echo 'int main() { return 0; }' > ret0.c $ use_cflags="--sysroot=$SYSROOT -g" $ ../build/bin/clang -o ret0 ret0.c ${=use_cflags} $ ls ret0 ret0.c ret0.dSYM $ rm -rf external ret0 ret0.* $ echo 'int main() { return 0; }' > ret0.c $ use_cflags="--sysroot=$SYSROOT -g" $ ../build/bin/clang -c -o ret0.o ret0.c ${=use_cflags} $ ../build/bin/clang -o ret0 ret0.o ${=use_cflags} $ ls ret0 ret0.c ret0.o I'd expect them to either consistently extract the dSYM or consistently lipo the slices together including the debug info. I don't have a strong opinion about which is right, it's just the inconsistency that's bothering me |
clang/lib/Driver/Driver.cpp | ||
---|---|---|
2037 | The reason they behave differently is because in the case where clang compiles + links in the same invocation the intermediate object files are deleted. In MachO we do not link debug information in ld, instead we do it in dsymutil. dsymutil cannot run across a temporary object file that has been deleted, so the clang driver runs it for you. Clang doesn't run it in the case of just linking object files because it takes time and isn't strictly required as long as you keep all your object files around so that your debugger can find the unlinked debug info in the object files. This is why one of the common ways people speed up debug builds with mach-o is to skip dSYM generation. |
Isn't that already based on isUsingLTO() and getLTOMode() or is there another bit? I'm looking at darwin::Linker::AddLinkArgs()
clang/lib/Driver/Driver.cpp | ||
---|---|---|
2037 | That makes sense. Although when you do want dSYM's, it does end up requiring the build system to know the logic clang is using and either move the one clang emitted or invoke dsymutil to make one depending on what clang did. At the moment, the options that cause dsymutil to be invoked by clang that I know of are -flto, compiling/assembling, and multiple values for -arch. It would be easier on the build system if it could force them to be emitted and control where they end up. |
clang/lib/Driver/ToolChains/Darwin.cpp | ||
---|---|---|
173 | Why not hoist the nullptr check into the assignment? if (Arg *A = Args.getLastArg(options::OPT_g_Group) if (!A->getOption().matches(options::OPT_g0) && !A->getOption().matches(options::OPT_gstabs)) return true; |
This should fix the same issue as the workaround I was using in D84127.
I'm not entirely convinced that this is all of it though. It seems strange to me that these two scripts produce different build products (aside from ret0.o):
I'd expect them to either consistently extract the dSYM or consistently lipo the slices together including the debug info. I don't have a strong opinion about which is right, it's just the inconsistency that's bothering me