* 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-) >> 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. >> 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. Thanks, Florian
