Clang does not allow generating dSYM bundle on macOS if using LTO and multiple arch's

[ychin]

Currently, on macOS, when compiling with -g, clang embeds the debug map inside the output program pointing to individual .o files for the full DWARF debug info. You can then use dsymutil to extract a .dSYM bundle that contains all the debug info that you can distribute separately.

However, this does not work if you are building with LTO (Link Time Optimization) and multiple arch's using the --arch command.

To reproduce this, do the following:

echo "int main() { return 0; }" > test.c

clang -arch x86_64 -arch arm64 -g -flto -c -o test.o test.c
clang -arch x86_64 -arch arm64 -g -flto -o program test.o
dsymutil program

You will see the following error message:

warning: (x86_64) /tmp/lto.o unable to open object file: No such file or directory
warning: (arm64) /tmp/lto.o unable to open object file: No such file or directory
warning: no debug symbols in executable (-arch x86_64)
warning: no debug symbols in executable (-arch arm64)

Note that the linker has an option (-object_path_lto) that is supposed to alleviate this by making a non-temporary lto.o, but it does not work in multi-arch set up because each pass overrides the last lto.o file. To repro:

clang -arch x86_64 -arch arm64 -g -flto -Wl,-object_path_lto,test_lto.o -o program test.o
dsymutil program

You will see from the results that one arch (arm64) got fixed, but not x86_64:

warning: (x86_64) test_lto.o unable to open object file: No object file for requested architecture
warning: no debug symbols in executable (-arch x86_64)

---

Note that there is a way to fix this by hacking how you compile. If you make an empty file empty_file.c, and the link it with the file, clang will automatically create a dSYM bundle for you so you don't have to use dsymutil to extract it:

touch empth_file.c
clang -arch x86_64 -arch arm64 -g -flto -o program test.o empty_file.c

We see:

> ls -d program*
program      program.dSYM/

This hack seemed to be used by https://reviews.llvm.org/D84127 itself. They filed a bug/PR to fix this properly in LLVM (https://bugs.llvm.org/show_bug.cgi?id=46841 and https://reviews.llvm.org/D84565) but the PR seems to not have been merged. It would have caused clang to automatically produce a dSYM whenever a temp lto.o is used because it's impossible to recover it afterwards.

Alternatively I feel that clang should have a command-line flag to control whether a dSYM bundle is generated. Currently I think it's quite odd that if you compile and link a program, it automatically generates a dSYM bundle because of an internal reason (it has to generate a temporary .o file that you can't recover later from the debug map); but if you compile and link separately, it won't generate a dSYM bundle. I think this should be exposed to the user instead of forcing the user to call dsymutil afterwards to extract the bundle (which in this case it doesn't work because the /tmp/lto.o is already gone). It would also simplify build scripts in being able to use a consistent set of compiler/linker flags without having to special case depending on how the program is built/linked.