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

[Joseph Myers <joseph at codesourcery dot com>]

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