stdlib: Make atexit to not act as __cxa_atexitazanella/atexit-order

This is patch to addresses the issue brought in recent discussion
regarding atexit and shared libraries [1] [2].  As indicated in the
libc-alpha discussion, the issue is since atexit uses __cxa_atexit
its interaction __cxa_finalize could lead to atexit handlers being
executed in a different order than the expected one.  The github
project gives a small example that triggers it [3].

The changes I could come with changes slight the atexit semantic
as described in my last email [4].  So basically the changes are:

  1. Add the __atexit symbol which is linked as __cxa_finalize in
     static mode (so __dso_handle is correctly set).  The __atexit
     symbol adds an ef_at exit_function entry on __exit_funcs,
     different than an ef_cxa one from __cxa_atexit.

     Old binaries would still call __cxa_atexit, so we do not actually
     need to add a compat symbol.

  2. Make __cxa_finalize to handle ef_at as well, similar to ef_cxa.

  3. Change how the internal exit handler are organized, so ef_at
     and ef_on handles (registered by atexit and on_exit) are executed
     before ef_cxa (registered by __cxa_atexit).

     Each entry set (struct exit_function_list) has on type associated
     (el_at or el_cxa) to represent the internal handle it contains.
     New insertions (done by the __atexit, __cxa_atexit, etc.) keep the
     node orders, with following constraints:

     3.1. el_at nodes should be prior el_cxa.
     3.2. el_at should contain only ef_at, ef_on, or ef_free elements.
     3.3. el_cxa should contain only ef_cxa or ef_free elements.
     3.4. new insertions on each node type should be be kept in lifo order.
     3.5. the original first element should be last one (since it is static
          allocated and 'exit' will deallocated the nodes in order.  */

     So the execution on both __cxa_finalize, exit, or quick_exit will
     iterate over the list by executing first atexit/on_exit handlers and
     then __cxa_atexit ones.  New handlers added by registered functions
     are handled as before, by using the ef_free entry and reseting the
     list iteration.

[1] https://sourceware.org/ml/libc-alpha/2019-06/msg00229.html
[2] https://sourceware.org/ml/libc-help/2019-06/msg00025.html
[3] https://github.com/mulle-nat/ld-so-breakage
[4] https://sourceware.org/ml/libc-alpha/2019-06/msg00231.html

0 files changed, 0 insertions, 0 deletions