site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt1383820pop.onmicrosoft.com; s=selector1-bt1383820pop-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G1EbH5mjzoGC30fDEuLl4VBwrRqWgDoFIPrOfORVoFo=; b=gjTCwDPDqebFJOH0fTL6SyvS5azh5aHIBwDudi2qShDmVV1f6IXcWFdWalMhbxNRoDzvXVee83Nie0fTOGRKrJziK9HL9kqdwJbBMNqQAAtyn1+pipGZeEAFX7at0HPOxJfvGX1tISz/Qfy2srov0Fwk8KJz/e15JAXRQMOGDJ8= Thread-index: AQHVLY/KE7tccurkME69bYl1K27WIA== 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 (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app... This email sent to site_archiver@lists.apple.com