[rfc][gold plugin] Fix pr19901

[Nick Lewycky]

Robinson, Paul wrote:
> Hope I'm not digressing too much (let me know) but...
>
>> I'm very sympathetic to the idea of not fixing libLTO and letting it rot
>> (oops, I meant to say letting Apple maintain it for ld64), though not doing
>> that would make ultimately make libLTO stronger. I'm calling this out as a
>> deliberate choice we have to make, we can either push libLTO to being well
>> enough designed to handle linkers with very different plugin ideologies (and
>> thus useful for others), or we can consign it to being an ld64 feature. If
>> gold can't use libLTO because its interface is too limiting, it's likely lld
>> won't either, that any third party linkers won't, etc.
>
> Uh... what?  We're actively pursuing LTO with our own linker, using (pretty
> sure) libLTO.
> Or has my irony/dry-wit filter failed again...

My point is that libLTO is essentially done from Apple's point-of-view 
and is in maintenance mode. While libLTO is really elegant, the problem 
is that it's also really narrow and doesn't match the things that other 
linkers -- or at least gold -- need to do. And some of those things are 
"because ELF" and some of them are just differences in the way that ld64 
and gold do their linking. From experience, trying to extend libLTO is 
really hard, yes there were a lot of improvements that were easy to make 
(adding linkage types to the enum) but some problems were subtle and 
would require architectural/design work.

The second problem is that the community doesn't have much experience 
doing llvm lto outside of ld64, and all (or nearly all) of that 
experience is with tools/gold. If we're taking tools/gold away from 
libLTO, then who in the community is going to design the interface that 
is elegant and efficient for both ld64 and gold, while maintaining the 
ABI of the existing libLTO? I don't think the llvm community today has 
the expertise necessary with LLVM LTO in native linkers to do that, 
after we exclude all the people using ld64 and tools/gold.

That said, feel free to prove me wrong. :) If you've got linker work 
using libLTO going on, I think you'll find yourself with a few options 
in the future. You can choose to make small improvements to libLTO (if 
that is sufficient, then you're likely using a similar linking model to 
ld64), to build a new API like libLTO that only services your needs but 
would probably be difficult for other linkers to use, to do the work of 
designing a combined interface that really would work for everyone, to 
make your linker use the LLVM C++ APIs directly, or to change your 
linkers internals to work the way libLTO wants you to. The last one 
isn't an option for tools/gold, and pragmatically we don't have the time 
to build a new all-encompassing interface.

Nick