Re: [PATCH 0 of 3] Add support for using gold instead of ld

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Bryan, Arnaud, All,

On Tuesday 28 December 2010 20:11:31 Bryan Hundven wrote:
> On Tue, Dec 28, 2010 at 10:02 AM, Yann E. MORIN
> <yann.morin.1998@anciens.enib.fr> wrote:
> > For now, I'll consider that --enable-gold will only build the lto plugin...
> Again. --enable-gold has been in gcc since 4.4, so --enable-gold just
> makes gcc use the gold linker.

But when I look at gcc trunk (aka 4.6) ./configure, --enable-gold sets
ENABLE_GOLD=yes

ENABLE_GOLD is used in ./configure to check gold vs. ld use, and then
conditionally sets only configdirs to include gold, and/or remove ld.

configdirs is used to descend into subdirs, but only if they exist.
Which means 'gold' or 'ld' in configdirs is a no-op, as gcc does not
have gold/ or ld/ at the top-level.

Then grepping -i ENABLE_GOLD in the source tree yields nothing, except
in the top-level ./configure script.

Then, looking at 'lto' in configure yields that ELF target *always*
enable the LTO plugin:
  6116:if test $target_elf = yes; then :
  6117:  # ELF platforms build the lto-plugin always.
  6118:  build_lto_plugin=yes

It also shows that lto is treated as a language (strange, isn't it? ;-):
  6243:      *) enable_languages="${enable_languages},lto" ;;

And finally, if build_lto_plugin is yes, then add lto-plugin to configdirs.

Also, enable_lto is used in a few places, where it then enables/disables
some code paths. It's limited to gcc/:
- gcc/collect2: because without support from the linker, it's collect2
  doing all the LTO stuff.
- gcc/opts.c: recongnise the -flto option
- gcc/configure & gcc/Makefile: OK, expected ;-)
- gcc/opts-global.c: (un)register LTO options callbacks
- Changelogs and such

OK, I still don't see how --enable-gold impacts building the lto-plugin.
And I still don't see if --enable-gold would call directly to ld.gold,
or would still call to ld.

Lets grep -E 'ld\.gold': yields only comments in top-level ./configure.

OK, grep 'fork_execute' in gcc/collect2.c: it always call "ld", without
any suffix.

OK, that was an interesting trip. Especially the part where I learnt
about the pex_init and pex_run on collect2. And also the part where I
realised I would get lost somewhere.

Well, again, all this was about gcc trunk, ie the future 4.6.

> If it isn't available, I'd guess that gcc's configure would bomb out
> because either ld.gold doesn't exist or ld doesn't look like a gold
> linker.

Nowhere did I see it would call directly to ld.gold (or even ld.bfd,
for that matter).
 
> LTO is in gcc 4.5 and greater, and it just so happens that binutils
> gained support for building linker plugins in 2.21...
> 
> Maybe specific versions of binutils should be paired with specific
> versions of gcc.

No, please, no!!... ;-)

From what I understand:
  LTO in gcc    ld is      lto-plugin    LTO handled by
  disabled      N/A        N/A           N/A
  enabled       ld.bfd     N/A           collect2
  enabled       ld.gold    missing       collect2 (?)
  enabled       ld.gold    present       gold with plugin

So, whatever the combination of binutils with or without gold, and gcc
with or whitout LTO, we get a working combination.

And even then, the third case should not happen, as the lto-plugin is
built unconditionnaly for ELF targets.

And because we won't --enable-gold in gcc without actually having gold in
binutils, we're safe.

Going back to the code now, will test different variants.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

--
For unsubscribe information see http://sourceware.org/lists.html#faq