[RFC] stdlib: Make atexit to not act as __cxa_atexit
Florian Weimer
fweimer@redhat.com
Mon Jul 8 13:57:00 GMT 2019
* Adhemerval Zanella:
> On 08/07/2019 08:16, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> For _dl_fini, we already have the link_map for object that calls
>>> __cxa_finalize. What we need is to filter out the exit handlers registered
>>> by the object itself, so its calls only the functions registered by the
>>> shared library referenced by the link_map.
>>>
>>> Not sure how easily we can accomplish it on exit handlers registration
>>> functions (the __dso_handler trick is to make this easier).
>>
>> We can find the object that contains the address of __dso_handle, either
>> at registration time (perhaps better, to keep dlclose cost lower), or
>> during _dl_fini.
>
> We currently have the following:
>
> (libdl) dlclose:
> \_ (ld.so) _dl_close_worker
> - run dt_fini_array
> \_ (libfoo.so) __do_global_dtors_aux
> \_ (libc.so) __cxa_finalize ((libfoo.so) __dso_handle)
>
> What you are suggesting, if I understood correctly is:
>
> (libdl) dlclose:
> \_ (ld.so) _dl_close_worker
> \_ (libc.so) __cxa_finalize ((libfoo.so) __dso_handle)
Yes.
> So what we need to get on _dl_close_worked is the (libfoo.so)
> __dso_handle value.
Or we call the internal equivalent of dladdr on the supplied
__dso_handle pointer when the handler is registered. I expect that will
result in a slightly smoother execution.
> We will need to handle some caveats, as to add symbol resolution for
> local symbols and handle libraries that does not have
> __do_global_dtors_aux (and thus no __dso_handle).
Then they rely on ELF constructors exclusively and there is nothing to
do? (And there could be __dso_handle present for other reasons, but we
would not necessarily know about it, given that it's not a dynamic
symbol, and cannot be.)
> I do think it is feasible, we can add a new field on the link_map to
> hold its value or find it on _dl_close_worker.
I don't think __dso_handle is guaranteed to be unique per object. 8-(
So we need to be a bit careful there.
>> Have you considered a design which puts the same handler entry on two
>> different lists?
>
> Yes, the problem is we need to handle multiple constraints:
>
> - Any function that register a new exit handle may be called from another
> one. For instance atexit my call atexit or __cxa_atexit may call atexit
> (or any combination).
>
> - The internal lists follow the GNU principle of adding no limit, so we
> support the minimal POSIX states using a static allocated initial list
> (so atexit can't fail due malloc failure), and we add a linked list
> to make it grow as requested.
>
> - We need to handle BZ#14333, so we need to stop new registered function
> once we are over iterating over the list. I don't think it would be
> possible with two lists, specially for the case where one callback
> can modify the another list.
It should be possible to have the entry in multiple lists if we add
reference counters.
More information about the Libc-alpha
mailing list