[PATCH 00/58] Hide internal functions in libc.so

[Florian Weimer]

On 09/01/2017 10:14 PM, Joseph Myers wrote:
> On Fri, 1 Sep 2017, Florian Weimer wrote:
> 
>> On 09/01/2017 07:59 PM, H.J. Lu wrote:
>>> On x86,
>>>
>>> # readelf -rW libc_pic.a | grep " __" | grep PLT32  | awk '{ print $5 }' | sort | uniq
>>>
>>> shows that many internal functions are called via PLT in libc.so.  This
>>> series of patches hides internal functions to allow direct access within
>>> libc.so and libc.a without using GOT nor PLT.
>> I think we need to automate the generation of hidden attributes (or the
>> hidden aliases).
> I'm not convinced, for the present patch series.  An internal function
> needs to be declared somewhere anyway, with or without an explicit hidden
> attribute, so putting the attribute there when declaring the function
> doesn't really complicate things.  (I do think that if the attributes are
> explicit, there should also be a test that any external symbol in an
> object going into a shared library, that doesn't end up as a (defined or
> undefined) dynamic symbol in that shared library, is hidden, so that
> adding a non-hidden internal function is immediately visible as a test
> failure.)

I was concerned about cross-architecture variance in this area.

But I presume we can just add a hidden alias and add the export to the 
relevant sysdeps Versions files, so that's not an actual blocker for 
explicit specification of visibility.

So the main issue here is testing that we do not regression in the 
coverage of hidden declarations.

Thanks,
Florian