Re: Evolution of ELF symbol management

[Zack Weinberg <zackw at panix dot com>]

On 10/18/2016 05:26 AM, Florian Weimer wrote:
> With this message, I want to start a discussion why this symbol
> mangling stops at glibc-internal cross-DSO references (or static
> linking).  Wouldn't other system libraries, such as libstdc++, glib,
> Qt and so on need to do the same thing?  After all, if Qt calls
> foo@GLIBC_2.31, and the main program defines foo (which the static
> linker automatically exports to enable interposition), we almost
> certainly would want Qt to continue to call foo@GLIBC_2.31, and not
> the potentially incompatible implementation of foo in the main
> program.
> 
> To keep things simple, I suggest that for all new function symbols,
> we declare __libc_foo in the header file, redirect foo to
> __libc_foo, export both at the same symbol version from the DSO, and
> make __libc_foo a strong definition and foo a weak one.  (We should
> not add new variable symbols.)
> 
> For existing symbols, we only do this if we receive reports of
> conflicts causing problems in the field.  In this case, we add
> __libc_foo and the redirect to the header file, and use the current
> symbol version for the __libc_foo export (not the one of foo).

I meant to respond to this last month but have not been able to scrape
time away from $DAYJOB until this week.  Apologies.

First, I don't have a problem with adding __libc_* aliases as
non-default but public alternative names, so that third-party libraries
can avoid namespace pollution in static linkage and/or choose to refer
to symbols that are more likely to get resolved to the C library's
export than to a colliding symbol in the main executable.  I'd reserve
that for cases where there is already a demonstrated need, though, such
as libstdc++.  I also don't have a problem with a hypothetical policy
that all new symbols that aren't in the current revisions of C+POSIX
should be given an impl-namespace name as their primary definition, with
the user-namespace name being a weak alias (but still the only name used
in the public headers).

I _do_ have problems with causing these symbols to be used by default.
My main concern is that I think it's tackling the problem in the wrong
place.  If we want to back away from the original principle that the
executable always wins, isn't an expanded version of -Bsymbolic mode
what's _really_ wanted?  That is, an opt-in link-time declaration that
you want all dynamic symbols resolved at load-time to the same library
that provided them at link-time.  Once that exists, we could try to move
slowly in the direction of turning it on by default, along with various
other "yes, fix the bug" linker toggles like -z relro and --as-needed.
Until and unless this possibility has been thoroughly explored and
determined unworkable, I will object to bulk addition of __libc_*
aliases, and to an "all new public prototypes must redirect to a
__libc_* alias" rule.

A secondary reason for not wanting __libc_* aliases to be activated by
default is that it doesn't seem to me that it actually solves the
problem.  Applications that _want_ to interpose are going to shift to
the __libc_* names; depending on what the headers actually do,
applications that don't care (but do define a conflicting symbol) might
wind up shifting to those names by accident.  __REDIRECT doesn't work
without GCC(-compatible) extensions, after all.  (I would not object to
a _documented and enforced_ set of GCC-compatible extensions being a
baseline requirement for use of glibc headers -- but that would need to
happen _first_.)

zw