Re: [RFC] Prevent tailcall optimizations of libdl functions

[Joseph Myers <joseph at codesourcery dot com>]

On Wed, 25 Jan 2017, Rich Felker wrote:

> > A conforming program does not use shared libraries other than those 
> > provided by the system and POSIX does not define any way to build shared 
> > libraries.  If shared libraries are supported as an extension, ISO C and 
> > POSIX impose no requirements on how symbol resolution semantics when that 
> > feature is used might differ from symbol resolution semantics when only 
> > standard features are used.
> 
> While this might be technically defensible, it's nonsensical in
> relation to actual practice, especially in the historical context
> where the GNU tools have treated static-linking/static-libraries as
> deprecated or at best second-class citizens. GNU libtool even makes it
> impossible to static-link except for libraries being built in-tree as
> part of the same package. As such, from the standpoint of a complete
> GNU system using GNU tools, dynamic linking all libraries is the de
> facto default, and for them not to have the semantics the C language
> defines is a bug.

I think of "the objects from your translation units must be linked 
together statically" (with shared libc etc.) as being like "you must use 
-std=c99 -pedantic and not use lots of other options for non-conforming 
modes" - part of the requirements for getting an implementation of certain 
corner cases of the standard.

Shared libraries have routinely had lots of system-specific aspects, and I 
think that sort of corner case of function pointer comparison not working 
when the pointers to certain functions are accessed from different 
libraries is well within the sort of thing that can be expected.

(That's apart from questions of how much of standard C semantics are meant 
to apply to standard library functions, which need not behave as if 
written in C.  You could read the standard text as disallowing aliasing 
between different standard library functions, which seems even more 
pointless.)

> > (I put stat in the category of "do this differently if we move to 
> > libc.so.7", i.e. replace the very old versioning mechanism by normal 
> > symbol versioning if making such an (unlikely) global ABI transition.)
> 
> I don't see any reason it couldn't be done in libc.so.6, still having
> the old xstat etc. symbols for compatibility but removing stat etc.
> from libc_nonshared.a and adding them to libc.so.6.

Though technically possible, it seems like it would be excessively 
confusing to have two different versioning mechanisms in use for the same 
set of functions, and insufficiently beneficial.

-- 
Joseph S. Myers
joseph@codesourcery.com