[patch] First step to fix pr11866 during LTO

[Bill Wendling]

On Sep 4, 2013, at 10:13 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:

>> Hi Rafael,
>> 
>> This looks very much like the "external names" interface that's already in place. I'm assuming that there's a fundamental difference between the two? Is it only so that you can differentiate between symbols whose addresses don't leak?
> 
> There is a fundamental difference. The "external names" list is a list
> of symbols that we absolutely must provide. The new list of "symbol
> table" symbols we can omit if the LLVM knows it is safe. I do agree
> that with two lists "external names" is a bit generic. Maybe
> "externally used" would be better.
> 
> For an example of the difference, consider a dynamic library being
> built from two TUs. Translation unit A in compiled to native
> (ELF/MachO/COFF) and translation unit B is compiled to IL. Translation
> unit A has a copy of inline function F. The translation unit B has a
> copy of the inline functions F and G.
> 
> Lets say the linker decides to go with the copy of F in B. This means
> that LLVM absolutely must produce F in the object file it passes to
> the linker, otherwise we will have an undefined reference. For G the
> situation is different. The linker tells us that it wants that
> function just to put on the symbol table. Not because some native file
> depends on it. With this information LLVM can now reason that since
> the function is a linkonce_odr and its address doesn't leak, it can be
> omitted. Any other shared library needing this function will have a
> copy of it.
> 
Ah! Okay, I see what you mean. Thanks for the explanation. :-)

-bw