[patch] First step to fix pr11866 during LTO

[Bill Wendling]

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

> It turns out to be fairly hard to fix pr11866 without LTO since we
> cannot mark a function hidden until we are sure there are no other
> uses or definitions of it in other translation units because of the
> way visibilities are merged.
> 
> During LTO on the other hand, the linker can easily let us know  that
> all it wants a symbol for is to put it in a symbol table. This is
> exactly what gold provides with the LDPR_PREVAILING_DEF_IRONLY_EXP
> resolution.
> 
> What the attached patch does is forward that to LTO and then to
> internalize. Internalize then uses the information to hide the symbol
> when possible. In this patch I have only implemented hiding when the
> symbol is also unnamed_addr. In a followup I will refactor some code
> out of GlobalOpt so that we can also hide symbols that are not
> unnamed_addr but whose address doesn't leak.
> 
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?

-bw