gcc: Enable __cxa_atexit for final GCC
PATCH 1/1 gcc: Enable __cxa_atexit for final GCC
This is what GCC manual says [1]:
-------------------------->8---------------------- --enable-__cxa_atexit
Define if you want to use __cxa_atexit, rather than atexit, to register C++ destructors for local statics and global objects.
This is essential for fully standards-compliant handling of destructors, but requires __cxa_atexit in libc.
This option is currently only available on systems with GNU libc
...
-------------------------->8----------------------
Important disadvantages of a simple atexit() are that [2]:
-------------------------->8----------------------
1999 C Standard only requires that the implementation support 32 registered functions, although most implementations support many more.
More important it does not deal at all with the ability in most implementations to remove DSOs from a running program image by calling dlclose prior to program termination. -------------------------->8----------------------
Essentially for initial GCC there's no point in enabling that feature as we're not going to build CPP applications wit hit.
Also it seems like all libc's we support in Buildroot (Glibc, uClibc and musl) support __cxa_at_exit() so enable it unconditionally.
[1] https://gcc.gnu.org/install/configure.html
[2] https://itanium-cxx-abi.github.io/cxx-abi/abi.html#dso-dtor-motivation
--- package/gcc/gcc-initial/gcc-initial.mk | 1 + package/gcc/gcc.mk | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)
package/gcc/gcc-initial/gcc-initial.mk +1 -0
@@ -40,6 +40,7 @@ HOST_GCC_INITIAL_CONF_OPTS = \ --with-newlib \ --disable-largefile \ --disable-nls \ + --disable-__cxa_atexit \ $(call qstrip,$(BR2_EXTRA_GCC_CONFIG_OPTIONS)) HOST_GCC_INITIAL_CONF_ENV = \
package/gcc/gcc.mk +1 -1
@@ -87,7 +87,7 @@ HOST_GCC_COMMON_DEPENDENCIES = \ HOST_GCC_COMMON_CONF_OPTS = \ --target=$(GNU_TARGET_NAME) \ --with-sysroot=$(STAGING_DIR) \ - --disable-__cxa_atexit \ + --enable-__cxa_atexit \ --with-gnu-ld \ --disable-libssp \ --disable-multilib \
Signature · 1 line
2.16.2
PATCH 1/1 gcc: Enable __cxa_atexit for final GCC
Quoted 10 lines · Alexey Brodkin
This is what GCC manual says [1]:
-------------------------->8---------------------- --enable-__cxa_atexitDefine if you want to use
__cxa_atexit, rather than atexit, to register C++ destructors for local statics and global objects.This is essential for fully standards-compliant handling of destructors, but requires
__cxa_atexitin libc.
For what is is worth, we enabled cxa_atexit in BR2_EXTRA_GCC_CONFIG_OPTIONS five years ago, to fix a crash that occurred when catching exceptions and logging them using a log system that used global variables. But we couldn't remember the details.
PATCH 1/1 gcc: Enable __cxa_atexit for final GCC
Hi Nicolas,
Quoted 8 lines · Nicolas Cavallari
Quoted 7 lines · Alexey Brodkin
This is what GCC manual says [1]:
-------------------------->8---------------------- --enable-__cxa_atexitDefine if you want to use
__cxa_atexit, rather than atexit, to register C++ destructors for local statics and global objects.
Quoted 8 lines
Quoted 3 lines
This is essential for fully standards-compliant handling of destructors, but requires
__cxa_atexitin libc.For what is is worth, we enabled
cxa_atexitinBR2_EXTRA_GCC_CONFIG_OPTIONSfive years ago, to fix a crash that occurred when catching exceptions and logging them using a log system that used global variables. But we couldn't remember the details.
So you've been using BR with cxa_atexit since then, right?
Or you mean it was enabled in upstream BR for some time and then reverted back to disabled state?
-Alexey
PATCH 1/1 gcc: Enable __cxa_atexit for final GCC
Hi Alexey,
Le 15/11/2018 ? 11:22, Alexey Brodkin a ?crit?:
Quoted 15 lines
Hi Nicolas,
Quoted 12 lines · Nicolas Cavallari
Quoted 10 lines · Alexey Brodkin
This is what GCC manual says [1]:
-------------------------->8---------------------- --enable-__cxa_atexitDefine if you want to use
__cxa_atexit, rather than atexit, to register C++ destructors for local statics and global objects.This is essential for fully standards-compliant handling of destructors, but requires
__cxa_atexitin libc.
Quoted 7 lines
Quoted 4 lines
For what is is worth, we enabled
cxa_atexitinBR2_EXTRA_GCC_CONFIG_OPTIONSfive years ago, to fix a crash that occurred when catching exceptions and logging them using a log system that used global variables. But we couldn't remember the details.So you've been using BR with
cxa_atexitsince then, right?
Or you mean it was enabled in upstream BR for some time and then reverted back to disabled state?
--disable-__cxa_atexit is present since 2002/2003 in Buildroot, I'm not sure the reason for disabling atexit is still relevant.
Best regards,
Romain
Quoted 7 lines
-Alexey
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
PATCH 1/1 gcc: Enable __cxa_atexit for final GCC
Hi Romain,
Quoted 23 lines · Romain Naour
Hi Alexey,
Le 15/11/2018 ? 11:22, Alexey Brodkin a ?crit :
Quoted 20 lines
Hi Nicolas,
Quoted 16 lines · Nicolas Cavallari
Quoted 10 lines · Alexey Brodkin
This is what GCC manual says [1]:
-------------------------->8---------------------- --enable-__cxa_atexitDefine if you want to use
__cxa_atexit, rather than atexit, to register C++ destructors for local statics and global objects.This is essential for fully standards-compliant handling of destructors, but requires
__cxa_atexitin libc.For what is is worth, we enabled
cxa_atexitinBR2_EXTRA_GCC_CONFIG_OPTIONSfive years ago, to fix a crash that occurred when catching exceptions and logging them using a log system that used global variables. But we couldn't remember the details.
Quoted 5 lines
Quoted 2 lines
So you've been using BR with
cxa_atexitsince then, right?
Or you mean it was enabled in upstream BR for some time and then reverted back to disabled state?--disable-__cxa_atexit is present since 2002/2003 in Buildroot, I'm not sure the reason for disabling atexit is still relevant.
For me there was a reason to get cxa_atexit enabled - SEGFAULT in one of Glibc tests on ARC so I do it it solves something as for whih problems that change might introduce I have no ideas :)
I did a build test with all libc's for x86 but nothing more serious.
Also if we look around we'll see
1. In OpenEmbedded it is enabled for everything except gcc-cross-initial:
https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-devtools/gcc/gcc-configure-common.inc#L59
https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-devtools/gcc/gcc-cross-initial.inc#L23
2. In Crosstool-NG it is enabled by default:
https://github.com/crosstool-ng/crosstool-ng/blob/master/config/cc/gcc.in#L270
3. In OpenWrt it is disabled only for uClibc, otherwise enabled:
https://github.com/openwrt/openwrt/blob/master/toolchain/gcc/common.mk#L170
So I think it looks promising.
-Alexey
PATCH 1/1 gcc: Enable __cxa_atexit for final GCC
In reply to Alexey BrodkinQuoted 19 lines · Alexey Brodkin
This is what GCC manual says [1]:
-------------------------->8---------------------- --enable-__cxa_atexitDefine if you want to use
__cxa_atexit, rather than atexit, to register C++ destructors for local statics and global objects.This is essential for fully standards-compliant handling of destructors, but requires
__cxa_atexitin libc.This option is currently only available on systems with GNU libc
...
-------------------------->8----------------------Important disadvantages of a simple
atexit()are that [2]:
-------------------------->8----------------------
1999 C Standard only requires that the implementation support 32 registered functions, although most implementations support many more.
Quoted 7 lines
More important it does not deal at all with the ability in most implementations to remove DSOs from a running program image by calling dlclose prior to program termination. -------------------------->8----------------------
Essentially for initial GCC there's no point in enabling that feature as we're not going to build CPP applications wit hit.
^^^^^^^ with it
But also, there's no point disabling the feature. So I'd set it to enabled in
both initial and final.
Quoted 3 lines
Also it seems like all libc's we support in Buildroot (Glibc, uClibc and musl) support
__cxa_at_exit()so enable it unconditionally.
Also, it seems that gcc's configure will default it to yes and do aAC_CHECK_FUNC(__cxa_atexit, ...) as well.
Finally, it looks like the handling of this option hasn't changed at all since
4.8, so we're safe in that aspect as well.
So, with the --enable in the common options:
Regards,
Arnout
Quoted 44 lines
[1] https://gcc.gnu.org/install/configure.html
[2] https://itanium-cxx-abi.github.io/cxx-abi/abi.html#dso-dtor-motivationSigned-off-by Alexey Brodkin <[email protected]>Cc Thomas Petazzoni <[email protected]>Cc Mark Corbin <[email protected]>Cc Romain Naour <[email protected]>Cc Peter Korsgaard <[email protected]>Cc Bernd Kuhls <[email protected]>Cc Claudiu Zissulescu <[email protected]>Cc Cupertino Miranda <[email protected]>Cc Vineet Gupta <[email protected]>--- package/gcc/gcc-initial/gcc-initial.mk | 1 + package/gcc/gcc.mk | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-)package/gcc/gcc-initial/gcc-initial.mk +1
-0@@ -40,6 +40,7 @@ HOST_GCC_INITIAL_CONF_OPTS = \ --with-newlib \ --disable-largefile \ --disable-nls \ + --disable-__cxa_atexit \ $(call qstrip,$(BR2_EXTRA_GCC_CONFIG_OPTIONS)) HOST_GCC_INITIAL_CONF_ENV = \package/gcc/gcc.mk +1
-1@@ -87,7 +87,7 @@ HOST_GCC_COMMON_DEPENDENCIES = \ HOST_GCC_COMMON_CONF_OPTS = \ --target=$(GNU_TARGET_NAME) \ --with-sysroot=$(STAGING_DIR) \ - --disable-__cxa_atexit \ + --enable-__cxa_atexit \ --with-gnu-ld \ --disable-libssp \ --disable-multilib \