This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 00/58] Hide internal functions in libc.so
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.)
> Any ideas how we can do this?
Well, an alternative to marking internal functions hidden would be to mark
exported functions (mostly but not entirely declared in the public
headers) as exported, and then build with -fvisibility=hidden. But that's
still a lot of declarations in source files. Maybe for each public header
you could compile an include of it with -D_GNU_SOURCE -aux-info to get a
list of functions (like conform/GlibcConform.pm does) and automatically
generate a header with a series of
extern __typeof (foo) foo __attribute__ ((__visibility__ ("default")));
declarations. (Note -aux-info only covers functions, not variables, and
the exported names may not always be the ones declared in the header. The
Versions files would be another source of information on what should be
exported.)
Now, currently getting a list of all public headers requires recursing
into each build subdirectory and doing something like the above would
require such recursing before any of the rest of the build could start -
and recursing into each subdirectory is serialized, and comparatively
slow. If it were helpful we could e.g. decide to put all public headers
either in an include-public directory, or in sysdeps directories, so e.g.
include-public/stdlib.h instead of stdlib/stdlib.h.
--
Joseph S. Myers
joseph@codesourcery.com