This is the mail archive of the libc-alpha@sourceware.org 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: __cxa_finalize/__dso_handle contract


On Mon, Apr 01, 2019 at 01:04:14PM -0700, Petr Hosek wrote:
> I'm working on crtbegin.o/crtend.o implementation for compiler-rt as
> part of the LLVM project (see https://reviews.llvm.org/D28791 for more
> details).
> 
> One suggestions that was raised in the review
> (https://reviews.llvm.org/D59264#1428785) is to stop differentiating
> between the shared and non-shared case (i.e. no crtbeginS.o) and
> instead use the same object for both cases. The implication of this
> change is that we would use
> 
> void *__dso_handle = &__dso_handle;
> 
> instead of
> 
> void *__dso_handle = (void *)0;
> 
> for the non-shared case. I've checked different libc implementations,
> and AFAICT glibc is the only one that differentiates between the two
> cases in its __cxa_finalize implementation.
> 
> In glibc's __cxa_finalize(void *d), a nonzero d has to match the value
> passed to __cxa_atexit but a zero d matches every function registered.
> So it matters that DSO fini calls use &__dso_handle to match their
> registrations for the dlclose case, but it also matters that the main
> executable fini call (i.e. exit itself, and resp. for quick_exit) use
> zero to run all the dtors at exit time.
> 
> However, it's not clear whether it needs to be that way, because DSO
> fini should run at exit time too, but it would be a change of how the
> dtors get run that might affect dtor order in some cases.
> 
> So my question is whether the dtor order is something that glibc users
> should rely on or whether this is considered (an unsupported) corner
> case and whether the suggested change to always use nonzero d even for
> main executable would break the existing contract between __dso_handle
> and __cxa_finalize for glibc?

There's no reason fixing this needs to result in any change in
behavior. Instead of just special-casing a null pointer, glibc could
special-case "null pointer or address in the range of the main
program's mapping".

There may however be versioning issues fixing this with respect to
version mismatch between components.

Rich


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