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: Rich Felker <dalias at libc dot org>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Martin Sebor <msebor at redhat dot com>
- Date: Thu, 17 Dec 2015 11:20:07 -0500
- 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> <567288CC dot 7000604 at redhat dot com>
On Thu, Dec 17, 2015 at 11:05:00AM +0100, Florian Weimer wrote:
> 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
> >>> 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.
> 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
I don't get what you mean by "per-DSO heaps". They're just working
with global data.
> Back in the pre-ELF days, shared libraries were a
> rather involved affair, so whether there was an exact equivalence is a
> bit muddy.
Pre-ELF, this stuff was all broken. The big accomplishment/appeal of
ELF was fixing the semantics of dynamic linking so that applications
and libraries would not have to be aware of the (previously
non-conforming) implementation details of the dynamic linking system.
> 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.
You absolutely do have to care unless you require dynamic linking,
which is not a reasonable behavior for library code. With static
linking there is only one "DSO" so "per-DSO model" is useless.