Re: Another way to salvage Annex K and its constraint handler

[Rich Felker <dalias at libc dot org>]

On Fri, Nov 20, 2015 at 09:45:04PM +0100, Florian Weimer wrote:
> On 11/20/2015 08:35 PM, Rich Felker wrote:
> 
> > dlopen is outside the scope, but the behavior of a conforming program
> > that just happens to be dynamic-linked rather than static-linked is
> > not outside the scope. You cannot just ignore the constraint handler
> > set by one function because it happened to be performed from code in a
> > different DSO. What DSO the code lies in is an implementation detail.
> > And of course such a "solution" does nothing for static linking
> > anyway.
> 
> I'm not sure if I agree, at least as far as C is concerned.  Windows has
> much more DLL-local state than we do, and that's not a reason why it's
> non-complaint.  With a functioning dlmopen, we get much more of such
> state, if we like it or not.

At least with the MS tools, Windows DLLs do not provide semantics
equivalent to linking their object files directly into the main
program. On the other hand, all Unix-like systems I'm aware of, and in
particular the ELF binary format, have gone to great lengths to make
it so that, in the absence of explicit use of extensions, a
dynamically linked conforming program behaves exactly the same way it
would if all its translation units were put together in the abstract
machine specified by the C standard.

> We already make many callbacks DSO-local (atexit, pthread_create_key),
> so that you don't get segfaults when a DSO is unloaded.  The constraint
> handler would just be another such callback, but there are other
> benefits as well (the locking aspect).

This actually results in conformance bugs; taking the address of one
of these functions gives a non-unique address. And passing that
function address to a function that happens to be in another DSO
results in utter chaos. This "solution" was not well-thought-out at
all, and comes from an era when glibc was full of such halfway-right
solutions that didn't get proper attention to correctness and where
questioning them was not permitted.

In any case, aside from the function address issues, these hacks to
not cause other observable misbehavior in conforming programs; they
only affect programs that use dlclose. Per-DSO constraint handlers on
the other hand would significantly change the program behavior.

The "right" solution to fix Annex K is thread-local constraint
handlers which a function can set before making calls and restore
after it finishes. But it's not clear to me that Annex K is even worth
fixing. Standard C functions outside Annex K, POSIX functions, and
_FORTIFY_SOURCE already achieve the various things Annex K might be
useful for (depending on how you setup the constraint handler) much
more cleanly and effectively than Annex K could.

Rich