This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linker symbol resolution differences with LTO.

> gcc -c 1.c  -ffunction-sections -flto
> gcc -c 2.c -ffunction-sections
> # Linker picks the definition of foo from 2.o
> ld 1.o 2.o -y foo
> 2.o: definition of foo

If you run "nm" on 1.o, I think you'll find that there are no symbols
defined other than a couple of __gnu_lto_ symbols. This indicates that
you're compiling to "slim" objects, which contain *only* intermediate
code. Without the LTO plugin, the linker will find nothing to link in
1.o. If you want the ability to link LTO-compiled objects without
using the LTO plugin, you'll want to use the -ffat-lto-objects option
the object file will contain not only the intermediate code (for use
with the linker plugin), but also regular object code that can be
linked without a plugin. In that case, linking with plain ld, without
the plugin, will pick the right definition of foo, but you will not
get any link-time optimization -- you'll get the same output you would
have gotten without any -flto options at all.

You're not really using LTO (*Link-time* optimization) unless you use
"gcc -flto" for the link step as well. The gcc driver will pass the
necessary options to the linker to have it call the LTO plugin, which
will re-invoke the compiler to translate the intermediate code into
final object code at link time. Furthermore, if you only compile one
file with -flto, you won't really be gaining much at all, since the
link-time optimization will not be able to perform any cross-module


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]