This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 1/3] Add native ELF and LTO support in collect2
- From: Andi Kleen <andi at firstfloor dot org>
- To: Diego Novillo <dnovillo at google dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, gcc-patches at gcc dot gnu dot org, Andi Kleen <ak at linux dot intel dot com>
- Date: Tue, 2 Nov 2010 12:41:12 +0100
- Subject: Re: [PATCH 1/3] Add native ELF and LTO support in collect2
- References: <email@example.com> <firstname.lastname@example.org> <4CCFF04D.email@example.com>
> Hm, why not just force the use of a linker that has plugin support?
I mainly did it so that the constructors etc. would be still
generated by collect2. But maybe that could be fully done
by the linker now. I must admit I don't understand all
the implications of such a change, so I preferred to keep
the old mode and just make it work with LTO symbol tables.
There's also two additional uses of this infrastructure
(which are not in this patchkit yet):
- Detect leftover non LTO code from earlier ld -r and use objcopy to copy
it to a new object file and include it. This can be easily done
with slim LTO.
The main use of that is handling .S files LTO build that uses ld -r.
Without it that code would disappear during LTO.
I need that for a project I'm interested in. This was the main
reason I implemented slim LTO in the first place.
- Automatic detection of LTO so that if a Makefile forgets
to add the lto options for the final link it would still work.
This is actually needed for a full gcc lto slim bootstrap right
now because libiberty doesn't set correct stage2/3 link flags.
Perhaps that's obsolete, if ld plugin support is universal
the plugin could be just enabled unconditionally. I was a bit
wary of this before because it would mean unconditional gold
and gold still seems to have trouble with some code.