This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]