Re: [RFC] stdlib: Make atexit to not act as __cxa_atexit

[Florian Weimer <fweimer at redhat dot com>]

* 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.