This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
considerations?  Back in the pre-ELF days, shared libraries were a
rather involved affair, so whether there was an exact equivalence is a
bit muddy.

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
exist yet.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]