Compiling with both -flto and -g -- is it supposed to work ?

Clang Frontend
1

Hello,

I'm wondering if compiling with both `-flto` and `-g` is supported. I could not find any open bug on the bugzilla and the documentation does not mention it should or should not work.

When I do that (I also use `-flto` at the link step), and open the generated executable in GDB (tried both 8.3.1 and 9.2), I get the following:

$ gdb --args python testing/process_to_debug.py 
GNU gdb (GDB) 8.3.1
Reading symbols from <executable>...

warning: `/tmp/lto.o': can't open to read symbols: No such file or directory.
(No debugging symbols found in <executable>)
(gdb) r
Starting program: /Users/Philippe/Logiciels/miniconda3/envs/gdb/bin/python testing/process_to_debug.py
[New Thread 0x1103 of process 75303]
warning: `/tmp/lto.o': can't open to read symbols: No such file or directory.

I get set breakpoints at symbol names, but can't `list` or see function arguments...

This is on macOS 10.11.6, using the pre-compiled clang from https://releases.llvm.org/download.html:
$ clang --version
clang version 9.0.0 (git://github.com/llvm/llvm-project.git 0399d5a9682b3cef71c653373e38890c63c4c365)

and the system linker (I do use the above clang as the driver for the link step) :
$ ld -v
@(#)PROGRAM:ld PROJECT:ld64-274.2
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
LTO support using: LLVM version 8.0.0, (clang-800.0.42.1)
TAPI support using: Apple TAPI version 1.30

For reference I tried with <executable> being Git and Python..
I also tried debugging with the system LLDB (lldb-360.1.70) and the latter does not complain when loading the executable, but I get pretty much the same behaviour, nothing more than function names are available...

Also, dwarfdump outputs:
$ dwarfdump git

2

Not sure how this works on MacOS where object files are needed for
debugging - on Linux lto works with -g because debug info is linked
into the final binary. (CC'd some Apple folks who might know how this
is supposed to work)

3

Hi David,

Not sure how this works on MacOS where object files are needed for
debugging - on Linux lto works with -g because debug info is linked
into the final binary. (CC'd some Apple folks who might know how this
is supposed to work)

Thanks.

I ended up making additional tests, and adding `-v` to the clang invocation
on a simple hello-world type project made me realize
that I need to add `-Wl,object_path_lto,lto.o` to the linking command
if doing compilation and liking in separate steps (as is usually
the case with Make- and Automake- based build system!)

This flag is automatically added by the driver if doing compilation+linking in a single step,
and if it is not passed to the linker, `man ld` reveals that the temporary object file used
for link time optimization is deleted after the linking step is finished, so the executable contains
a reference to `/tmp/lto.o` which does not exist anymore when debugging actually starts
(I guess this path is hardcoded in ld64's code, I haven't checked that.)

Adding the flag as above keeps `lto.o` in the build directory, and debuggers are able to read
the debugging symbols. Also, `dsymutil`can then be run manually to create the dSYM bundle (which
is also done automatically if compiling and linking in a single step).

I'm not sure anything can be done to improve the situation... maybe add some notes in the
LTO documentation ? I could try to do that.

Cheers,
Philippe.

4

Yeah - wherever you think extra info might've helped hasten your
discovery would be great, thanks!