Summary

apache/nuttx-apps#3762 builds the FDPIC test modules of examples/fdpicxip and testing/fs/xipfs the normal way, with MODULE = m and DYNLIB = y. That puts a stripped module, a CMake shared library and a lazy PLT through the FDPIC path for the first time, and four defects show. Two more show with #20132, the first FDPIC configuration in CI, and the first one built with optimization. Each commit fixes one:

• mps2-an500 sets LDELFFLAGS to -r -e main after it includes Toolchain.defs, so a module links as a relocatable object, and a module that names a library does not link. dae3b8e removed the same lines from mps3-an547.
• libelf_findsymtab() accepts only SHT_SYMTAB. With CONFIG_DEBUG_SYMBOLS the application build strips each module, and a stripped shared object has only SHT_DYNSYM. Every module then fails to load with "No symbols in ELF file".
• The CMake build gives a shared library neither -mfdpic nor the FDPIC link, only -r.
• gnu-elf.ld.in names neither .rel.plt nor .got.plt. The linker merges .rel.plt into .rel.dyn but sets DT_JMPREL as if it came last, and puts .got.plt after .got. A module that calls its imports through a PLT jumps into data.
• GCC before 14 does not pass --fdpic to the assembler for -mfdpic, and the assembler rejects every FDPIC relocation: Relocation supported only in FDPIC mode. The CI image has GCC 13.2, so crt0.o of an FDPIC configuration does not build there. This is the CI failure of [10/10] Documentation, boards/rp23xx: Describe FDPIC and add a test configuration #20132.
• With -mfdpic and -mlong-calls, GCC turns a call in tail position into ldr r3, [r9, #off]; bx r3. The GOT slot holds the address of the function descriptor, so the branch goes to the descriptor in RAM, not through it. GCC 13.2 and 15.3 both do this, and only in an optimized build. The constructor of the C++ test library ends in a call to syslog(), so the test faults at "stage the C++ module". The fix passes -fno-optimize-sibling-calls.

Impact

Only CONFIG_FDPIC changes, except in the first commit, which gives mps2-an500 the common ELF link flags that the other boards use. Five boards still set their own LDELFFLAGS and so still cannot build an FDPIC module: devebox-stm32h743, weact-stm32h750, weact-stm32h743, openh743i and linum-stm32h753bi. They also name binfmt/elf/gnu-elf.ld, which no longer exists. I did not change them, because I cannot test them.

Testing

Host: macOS arm64, Arm GNU Toolchain 15.3.rel1 and 13.2.rel1 (the CI version), arm-uclinuxfdpiceabi binutils, QEMU 11.0.0.

mps2-an500:xipfs with CONFIG_FDPIC, on master with apache/nuttx-apps#3762, the same with both compilers:

xipfs_test fdpic    ==== 34 passed, 0 failed ====
xipfs_test reject   ==== 7 passed, 0 failed ====
fdpicxip jmprel     [lazymod] called through a DT_JMPREL descriptor, seed 42

Without each commit:

1. arm-uclinuxfdpiceabi-ld: attempted static link of dynamic object when cxxuser links against libshape.so.
2. libelf_findsymtab: ERROR: No symbols in ELF file for every module, and 14 passed, 20 failed.
3. CMake: multiple definition and dangerous relocation when a module links against a DYNLIB library.
4. fdpicxip jmprel ends in a usage fault. With the .got.plt half only, it ends in a bus fault in lib_realpath(), which the PLT slot of atoi() was bound to.
5. GCC 13.2: Error: Relocation supported only in FDPIC mode for every FDPIC object, crt0.o first.
6. mps2-an521:xipfs with CONFIG_DEBUG_FULLOPT, under QEMU: a hard fault at "stage the C++ module", with PC = R3 = 0x380509a0, a descriptor in RAM. With the fix: xipfs_test fdpic 34 passed, reject 7 passed, and all four fdpicxip demos run.

Under CMake, every module and library now links as an FDPIC shared object. The image itself does not link, because CMake does not generate the CONFIG_EXECFUNCS_SYSTEM_SYMTAB table. That is the same on master.

mps2-an500:xipfs and mps2-an521:xipfs, which do not set CONFIG_FDPIC, build. tools/checkpatch.sh -c -u -m -g passes.