You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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.
The text was updated successfully, but these errors were encountered:
ychin
changed the title
Clang does not allow generating a dSYM file on macOS if using LTO and multiple arch's
Clang does not allow generating dSYM bundle on macOS if using LTO and multiple arch's
Oct 28, 2024
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 usedsymutil
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:
You will see the following error message:
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:You will see from the results that one arch (arm64) got fixed, but not 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 usedsymutil
to extract it:We see:
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.The text was updated successfully, but these errors were encountered: