casaroli opened a new pull request, #20048: URL: https://github.com/apache/nuttx/pull/20048
## Summary A C++ ELF module that holds a static object does not link. GCC registers each such object's destructor with `__cxa_atexit(dtor, obj, &__dso_handle)`, and `__dso_handle` comes from crtbegin, which a module does not link: ``` hello++3.cxx:119: undefined reference to `__dso_handle' ``` `-fno-use-cxa-atexit` registers the destructors with `atexit()` instead, which puts them in `.fini_array`. That is where `libelf_uninit()` looks for them when the module is unloaded, so the flag that makes the link work also makes the destructors run. The flag goes wherever `CXXELFFLAGS` is defined: the architecture `Toolchain.defs` and the boards that reassign it. The toolchains that are not GCC or Clang are left alone: ceva, tricore, z16 and the z80 family. The CMake build sets it once, beside the include of the architecture `elf.cmake`, under a generator expression, because the option is valid for C++ alone and GCC warns about it on a C compile. Split out of #19940 at the request of a review comment there. It is not FDPIC specific and fixes a failure that is present today. ## Impact Fixes an ELF module link failure for C++ modules with static objects, and makes their destructors run on unload. No behaviour changes for C modules. ## Testing `apps/examples/elf` on `mps3-an547:picostest` with `CONFIG_PIC` enabled: `hello++3` fails to link before this change and links after. The make build was checked with `make -pn` on `pimoroni-pico-2-plus:nsh`, which shows the flag in `CXXELFFLAGS`. The CMake build configures cleanly for the same board. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
