ABI for atexit and static termination routines.
ABI for atexit and static termination routines.
- Subject: ABI for atexit and static termination routines.
- From: Software Developer via Darwin-dev <email@hidden>
- Date: Fri, 28 Jun 2019 08:59:27 +0000
- Thread-topic: ABI for atexit and static termination routines.
Do we have a formal ABI specification for the order in which termination
routines (for example, specified in mod_term_func / __DATA,__mod_term_func
sections) are executed with respect to functions registered via atexit?
For example, SysV ABI doc says:
"Termination functions specified by users via the atexit mechanism must be
executed before any termination functions of shared objects.”
(my note: ^^^ termination functions specified in .fini sections for ELF
platforms, for example)
The posix standard atexit entry is silent on ordering w.r.t static termination.
——
This (SysV spec) is not the current situation on Darwin-based systems, where it
appears that the __DATA,__mod_term_.func functions are executed _before_ the
ones registered via atexit.
=====
Anyway, this means that one doesn’t end up with a strict nesting of ctor/dtor
in the case that we have static c++ ctor/dtors in the same context as ones
specified by __attribute__ ((constructor))/ __attribute__ ((destructor)), since
the static c++ dtors get run via atexit
.. and end up *after* the ones run for __attribute__ ((destructor)),
whereas the ctors for __attribute__ ((constructor)) are run *before* the c++
static ctors.
so we get
attr_constructor_ctor
cxx_ctor
attr_destructor_dtor
cxx_dtor
instead of (what the user might expect)
attr_constructor_ctor
cxx_ctor
cxx_dtor
attr_destructor_dtor
(with GCC the -fno-use-cxa-atexit is honoured, and we can get to expected
nesting [because that forces the c++ dtor into the .mod_term_funcs section]
however, with Xcode/LLVM the flag doesn’t appear to have that effect).
So .. I am not sure if this is a bug, or an intention of the ABI - and need to
figure this out in order to know how to solve the problem (conflict in
expectations between sysv-based tests and darwin) in my toolchains.
thanks
Iain
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden