On 7/1/25 10:57 AM, Florian Weimer wrote:
* Jason Merrill:
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.
Hmm, that's a fair point. I didn't realize that they could use atexit
directly.
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).
It just occurred to me that linking shared libraries usually doesn't use
-Wl,-z,defs yet, so you would just get underlinking as before. So
-nostartfiles probably is not needed after all.
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?
I found this one:
<https://sources.debian.org/src/firefox-esr/128.12.0esr-1/third_party/libwebrtc/build/config/coverage/BUILD.gn/?hl=31#L31>
That has a comment that it's probably wrong and should be removed. The
patch that added it claimed that it was to avoid an undefined symbol
error for plain atexit (not __cxa_atexit), which makes no sense.
Possibly more could be discovered by poking around in Debian Code Search
<https://codesearch.debian.net/search?q=fno-use-cxa-atexit&literal=1>.
Thanks for the pointer. Outside of compiler testsuites:
https://sources.debian.org/src/scalene/1.5.51-1/vendor/printf/Makefile/#L146
https://sources.debian.org/src/pico-sdk/2.1.1-1/src/rp2_common/pico_cxx_options/CMakeLists.txt/?hl=25#L25
These look either unneeded for embedded use or wrong when used on a
hosted system; the target toolchain will already disable the flag if
appropriate. Possibly these uses date back to before that was true.
https://sources.debian.org/src/intel-graphics-compiler/1.0.17791.18-1/IGC/CMakeLists.txt/?hl=1097#L1097
This claims to be working around a bug in Android __cxa_atexit.
Hopefully that has been fixed by now.
https://sources.debian.org/src/intel-gmmlib/22.7.2+ds1-1/Source/GmmLib/Linux.cmake/?hl=129#L129
https://sources.debian.org/src/intel-media-driver/25.2.3+dfsg1-1/media_driver/cmake/linux/media_compile_flags_linux.cmake/?hl=99#L99
I'm guessing these are cargo cult copying from the instance above,
wrongly passed on from android to linux configurations.
So, some packages that are using the flag incorrectly might be
encouraged to stop doing so (if they care about the warning). It
doesn't seem that any of these would actually break.
Jason
