On 6/30/25 5:22 PM, Florian Weimer wrote:
* Jason Merrill:
On 6/28/25 3:17 PM, Florian Weimer wrote:
* Jason Merrill:
Since r10-6069[1] we control the call to __cxa_finalize with
DEFAULT_USE_CXA_ATEXIT, so there's no need to also declare it as a weak
reference; if the target has __cxa_atexit, it must also have __cxa_finalize.
I expect that most targets do not need __cxa_finalize. They can run
the registered destructors directly, without waiting for a call to
__cxa_finalize.
AFAICT glibc still uses __cxa_finalize to run destructors on dlclose;
at least that's what its comment says.
Yes, but for most target processors, there is a variety of targets which
don't do this (no dlclose …), hence “most targets” is still true.
Maybe. 8-)
But if those targets don't have dlclose, they don't need __cxa_atexit
and should (and probably do) leave default_use_cxa_atexit off in config.gcc.
I think with your patch, libc will is always linked in as well,
assuming that it's the source of the __cxa_finalize definition.
True, so that's not a difference for __cxa_atexit targets.
Existing targets that reuse the glibc toolchain will have to do
something about __cxa_finalize after your change goes in, though.
If they're linking shared libraries (which seems unlikely in your
bootloader scenario below).
The difference between the --push-state solution and the patch is that
on glibc-like targets, a conditional branch during startup is avoided.
And it will be necessary to link with --nostartfiles in more cases (or
provide a dummy definition of __cxa_finalize).
Or properly configure the compiler with --disable-__cxa_atexit.
The point of my patch is that this should be (and already halfway is)
a configure-time choice, not something that can change from one TU to
another.
I'm not sure if that's what our users expect. Common practice is to use
*-linux-gnu targets to build bootloaders, kernels and whatnot using the
same toolchain, and not create a separate *-none target with different
configure options. I think that's … not great for full libc targets
(where the toolchain may end up supporting GNU-style symbol versions,
but the dynamic linker does not). But for more limited bootloader-type
scenarios (no full libc, no dynamic linking), it evidently works quite
well so far.
Interesting point, are there in fact such packages that rely on
-fno-use-cxa-atexit?
Jason
