casaroli opened a new pull request, #20846: URL: https://github.com/apache/nuttx/pull/20846
## Summary With `CONFIG_LTO_FULL` (GCC), the `Toolchain.defs` of arm, arm64 and risc-v set `LD` to the gcc driver, and a loadable module (and a program of a kernel build) is linked with it, because `MODULELD` defaults to `LD`. The partial link (`-r`) of LTO objects keeps only LTO data, which the loader cannot use: `exec failed: 22`, and `nm` says `plugin needed to handle lto object`. When `MODULELD` is gcc and the link is partial, `LDMODULEFLAGS` and `LDELFFLAGS` now get `-flinker-output=nolto-rel` and the compile options of the module, where these variables are first set. The link then compiles the objects to machine code with the options of the module (`-mthumb`, `-mlong-calls`, ...). Without these options the arm-none-eabi assembler stopped with `invalid constant (3e8) after fixup`. `-Wno-error` comes last, because LTO warns that crt0 and the program declare `main()` differently. This replaces the `Make.defs` part of apache/nuttx-apps#3884, as asked there. That PR keeps only the `-Wl,--defsym=` form of the program attributes for the gcc driver; a module links only with both. ## Impact - `CONFIG_LTO_FULL` with GCC on arm, arm64 and risc-v, with loadable modules or a kernel build: the modules link to machine code and load. - Without LTO, with clang (ld.lld) or with FDPIC (`MODULELD` is ld): no change. - No documentation change. ## Testing `qemu-armv8a:nsh` (flat, Arm GNU 14.2, QEMU HVF) with `CONFIG_LTO_FULL`, `CONFIG_ELF`, `CONFIG_EXECFUNCS_SYSTEM_SYMTAB` and `CONFIG_EXAMPLES_HELLO=m`, apps with apache/nuttx-apps#3884, `hello` loaded from a 9p share: | | master | this PR | |---|---|---| | `hello` link | `-Wl,--defsym=...` only | `-flinker-output=nolto-rel`, the module options, `-Wno-error` | | `nm hello` | `plugin needed to handle lto object` | 18 defined symbols, no LTO data | | run | `nxposix_spawn_exec: ERROR: exec failed: 22` | `Hello, World!!` | `tools/checkpatch.sh -c -u -m -g` passes. -- 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]
