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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
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
----------------------------------------------------------------------
 File: git (x86_64)
----------------------------------------------------------------------
.debug_info contents:
< EMPTY >

Is this normal behaviour ?

Thanks,
Philippe.
P.S.: this is my first time posting here so don't hesitate if more information is needed.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
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)

On Tue, Jun 9, 2020 at 12:15 AM Philippe Blain via cfe-dev
<[hidden email]> wrote:

>
> 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
> ----------------------------------------------------------------------
>  File: git (x86_64)
> ----------------------------------------------------------------------
> .debug_info contents:
> < EMPTY >
>
> Is this normal behaviour ?
>
> Thanks,
> Philippe.
> P.S.: this is my first time posting here so don't hesitate if more information is needed.
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
Hi David,

> Le 9 juin 2020 à 11:16, David Blaikie <[hidden email]> a écrit :
>
> 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.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

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

Vassil Vassilev via cfe-dev
On Thu, Jun 11, 2020 at 7:56 PM Philippe Blain
<[hidden email]> wrote:

>
> Hi David,
>
> > Le 9 juin 2020 à 11:16, David Blaikie <[hidden email]> a écrit :
> >
> > 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.

Yeah - wherever you think extra info might've helped hasten your
discovery would be great, thanks!
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev