[rfc][gold plugin] Fix pr19901
Rafael EspĂndola
rafael.espindola at gmail.com
Tue Aug 5 18:02:44 PDT 2014
>> I am going on vacations tonight, so I don't think I will have time to
>> finish this until I get back (20th), but I wanted to send out a
>> preview of the patch so that others can take a look.
>>
>> The fundamental issue with that bug is the api mismatch between gold
>> and our own LTO api. The gold api talks about "symbol foo in file
>> bar". Our api talks about "symbol foo in the merged module".
>>
>> In that particular testcase, what happens is that gold asks us to keep
>> a particular linkonce_odr symbol, but the IR linker doesn't copy it to
>> the merged module and we never have a chance to ask lib/LTO to keep
>> it.
>
>
> Why is that not the bug? The linker can't assume that all callers are
> visible, just that it's merging two modules. A flag for the linker that
> tells it that it can see the whole program and therefore may drop linkonce
> symbols sounds like a nice optimization, but not correct in general.
>
I would call it a missing feature. It is not as bad as assuming a
whole program. What the the current design of lib/Linker assumes is
that each module in "independent" given the IR semantics. By
independent I mean things like "no undefined reference to a
linkonce_odr", which follows from the rule than an unused linkonce_odr
can be dropped.
What causes problems is the the plugin API expects us to be more
flexible than that. It expects to be able to tell us to keep a
linkonce_odr and use it from a native ELF file, effectively creating
an undefined reference to a linkonce_odr. I think the best way to
think about it is that during the linking process the modules can
transit through invalid states (like having a linkonce_odr that must
be kept) but the linker (gold+plugin, not lib/Linker) knows how to
patch things up in the end.
What this patch does is a small dance to make each module look
individually valid. That is why it sometimes replaces linkonce_odr
with weak_odr or an alias with a variable declaration. This is a bit
of a hack, but is the least invasive change that fixes the bug and
gets the test passing.
With that in I then hope to add support for COMDATs and then make the
lib/Linker interface more flexible. It should be possible to, for
example, directly say that a linkonce_odr must be copied and that a
given alias must not.
Cheers,
Rafael
More information about the llvm-commits
mailing list