This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Linker symbol resolution differences with LTO.
- From: Cary Coutant <ccoutant at gmail dot com>
- To: Shankar Easwaran <shankarke at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Mon, 7 Dec 2015 17:20:52 -0800
- Subject: Re: Linker symbol resolution differences with LTO.
- Authentication-results: sourceware.org; auth=none
- References: <loom dot 20151208T011805-238 at post dot gmane dot org>
> 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
optimization.
-cary