This is the mail archive of the
mailing list for the glibc project.
Re: Another way to salvage Annex K and its constraint handler
- From: Florian Weimer <fweimer at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Martin Sebor <msebor at redhat dot com>
- Date: Thu, 17 Dec 2015 11:05:00 +0100
- Subject: Re: Another way to salvage Annex K and its constraint handler
- Authentication-results: sourceware.org; auth=none
- References: <564F3982 dot 5020504 at redhat dot com> <20151120193519 dot GY3818 at brightrain dot aerifal dot cx> <564F8650 dot 3080500 at redhat dot com> <20151120213551 dot GZ3818 at brightrain dot aerifal dot cx>
On 11/20/2015 10:35 PM, Rich Felker wrote:
> 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
>> 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.
It's still surprising how many APIs (libresolv, get*ent) were designed
so that they work with per-DSO heaps. Was this just due to performance
considerations? Back in the pre-ELF days, shared libraries were a
rather involved affair, so whether there was an exact equivalence is a
Anyway, I brought this up because I do think that for the Annex K
constraint handler, the per-DSO model is much more useful to programmers
than the per-thread model. With the per-DSO model, you don't usually
have to care about constraint handlers in a library at all. With the
per-thread model, you have to set and restore the constraint handler
around any use of Annex K functionality, which pretty much kills the
entire thing due to inconvenience.
> 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.
Correct, but it would be acceptable because those interfaces do not