Evolution of ELF symbol management

[Joseph Myers]

On Tue, 25 Oct 2016, Florian Weimer wrote:

> > There are a few existing __libc_foo exports at public symbol versions.  Do
> > all those satisfy the rule that where both foo and __libc_foo exist, the
> > latest version of foo and the latest version of __libc_foo are aliases or
> > otherwise have the same semantics?  (It would seem very confusing for old
> > and new __libc_* symbols to follow different rules in that regard.)
> 
> I found a few symbols which differs in the exported version.  The unprefixed
> symbol has a regular version, and the prefixed one appears as GLIBC_PRIVATE.
> These are:
> 
> clntudp_bufcreate
> fork
> longjmp
> pread
> pwrite
> secure_getenv
> siglongjmp
> system
> vfork

My concern is mainly about __libc_* symbols at public versions, not 
GLIBC_PRIVATE, since we can freely change the ABIs for __libc_* at 
GLIBC_PRIVATE if those are confusing.

> > Right now we have
> > many individual #defines in the case where __REDIRECT is not supported.
> > If we required support for asm redirection in compilers using the glibc
> > headers, it would be possible to define a macro to declare both foo and
> > __libc_foo, with the same type and the same attributes (and the same throw
> > () information for C++), and do the redirection, all with one macro call.
> > Otherwise you get a lot of repetitive boilerplate in headers for every
> > such function, since a macro cannot generate a #define of another macro.
> > Or you say that compilers without redirection support don't get any of
> > these redirections, since they are not semantically required.
> 
> Unfortunately, I forgot an important detail:
> 
> Even in the __GNUC__ case, we need more than just the declaration.  If we just
> set an asm alias, an interposing definition supplied by the user will happily
> interpose the supposedly-protected alias.
> 
> This is less relevant for functions in non-standard headers (which
> applications would not include accidentally), but if we add something to
> <stdio.h> (under _GNU_SOURCE) which is ripe for collisions, we need to somehow
> make sure that a user-defined function of the same name does not end up
> interposing the alias.

Same name and type, that is; if the type is wrong and the header 
declaration is visible, a compile-time error will occur.

> The easiest way to do this is to add a function-style macro which expends to
> something that cannot be parsed as part of a function definition.  We
> discussed using inline functions for this, but this appraoch was rejected due
> to standards compliance concerns.  But maybe the desire to put all this in a
> single macro definition will make us reconsider.  On the hand, inline
> functions are particularly hard on some wrapper generators.  The internal
> binding generator of LuaJIT, for example, supports asm aliases, but ignores
> inline functions.

There is always the option of having the installed headers be generated 
files, so the source tree has .h.in files that contain some sort of 
annotations for use by a special glibc-specific preprocessor that does 
things the C preprocessor cannot - converting something that looks like a 
C macro call (say) into function declarations, __REDIRECT calls - and 
function-like macro definitions.  Of course then you need to get those 
headers generated at an early stage in the glibc build.

Or define a new function attribute whose meaning is that the asm 
redirection is disregarded if defining the function, but then user code 
would only be protected against accidental interposition when built with a 
compiler supporting that new attribute.

> I think this leads to the question whether we should prefer __ over __libc_
> after all because as part of fixing the glibc-internal linknamespace issues,
> we often added a __ symbol with a public version (but sometimes a

We shouldn't have added them with public versions, just internally (and 
only at GLIBC_PRIVATE if needed by a separate library from the 
definition).

-- 
Joseph S. Myers
joseph@codesourcery.com