[5.5/10] arch/arm, cmake: Build FDPIC modules in the normal ELF build. by casaroli · Pull Request #19940 · apache/nuttx

casaroli · 2026-08-23T21:07:52Z

Summary

This replaces what this PR was. It added tools/fdpic, a module build of its own; review asked instead that FDPIC go into the normal in-tree ELF build. So it does, and tools/fdpic is not added at all.

With CONFIG_FDPIC, a module built by apps/Application.mk is an FDPIC shared object. Same MODULE = m, same crt0.c, same linker script.

Two things differ from the position independent build beside it: the compiler is told -mfdpic -fPIC, and the link is done by an arm-uclinuxfdpiceabi linker. Only the link needs it; the stock compiler emits correct FDPIC objects for C and C++, its assembler included. That linker is in the CI image since #19992, and the build says so if it is missing.

The stock linker must not be fallen back to, because it does not refuse FDPIC objects. It marks the output UNIX - System V and turns every import into an R_ARM_JUMP_SLOT, one word, where the ABI wants an R_ARM_FUNCDESC_VALUE, which is two: a code address and the data base that goes with it. The module links cleanly and then calls out of itself with the caller's data base still in r9.

gnu-elf.ld.in gains the two segments an FDPIC module needs, under CONFIG_FDPIC, and names .dynamic. The sections and the symbols crt0.c walks are untouched, so one script serves both cases and both build systems.

.bss moves to the end of the script, for every configuration and not only FDPIC. It holds no file content but sat ahead of .got and .dynamic, which do, so the writable segment's p_filesz had to span it and the module file carried the whole of .bss. A module with 16 KiB of .bss goes from 26724 to 10340 bytes, and its writable segment from p_filesz 0x40ac to 0xac against an unchanged p_memsz. The loader reads p_filesz off the media, so it read those bytes too.

The __dso_handle commit that was here is now #20048. It is not FDPIC's, and review asked for it across the other architectures.

This comes after [5/10] #19942 rather than before it, because CONFIG_FDPIC is defined there.

Impact

Nothing changes with CONFIG_FDPIC off, which is every configuration in the tree.

With it on, a module needs the arm-uclinuxfdpiceabi linker. Anyone selecting the option needs it anyway.

.bss last changes the layout of every ELF module, not only FDPIC ones. The module gets smaller and the loader reads less; nothing else moves, because the loader places by section flags and the _sbss/_ebss symbols are unchanged.

Testing

mps3-an547:picostest with apps/examples/elf, CONFIG_FDPIC both ways, through make and cmake.

$ readelf -h apps/bin/hello++3
  OS/ABI:      ARM FDPIC
  Type:        DYN (Shared object file)
  Entry point: 0x81
$ readelf -d apps/bin/hello++3
  0x19 (INIT_ARRAY)  0x1018
  0x1a (FINI_ARRAY)  0x101c

Every module in apps/bin is an FDPIC shared object with two PT_LOAD segments entering at _start. hello++3 has a static C++ object, so it carries both arrays; it needs #20048 to link at all.

With CONFIG_FDPIC off the tree builds as before and the generated script has no PHDRS. With the linker off PATH a module link stops with a message naming it, and make distclean still works.

tools/checkpatch.sh -c -u -m -g and cmake-format --check pass.

The fixtures in apps/examples/fdpicxip keep a build of their own, because they are loader edge cases Application.mk cannot express. apache/nuttx-apps#3762 moves it there so NuttX carries none of it.

github-actions · 2026-08-23T21:14:48Z

MemBrowse Memory Report

No memory changes detected for:

The modules this example and testing/fs/xipfs carry are built by an explicit 'make regen', which reached into nuttx/tools/fdpic for a makefile that builds a module, a script that turns one into a header, and two more that checked its imports. Review of apache/nuttx#19940 asked that NuttX not carry a module build of its own, and it no longer does: with CONFIG_FDPIC an ordinary FDPIC module is built by apps/Application.mk like any other. These are not ordinary modules, which is why they keep a build of their own. They are fixtures for loader edge cases: a library with a SONAME, a module with more DT_NEEDED entries than the loader will follow, one whose imports stay in the lazy binding table, and one naming a symbol the firmware does not export, which exists to be refused. Application.mk cannot say any of that. So the build stays, and it is here beside them rather than in NuttX. It is also much smaller. The generic module makefile is gone: it existed to be included by anything, and only this one directory ever did, so its dozen useful lines are rules here. fdpic-embed.py is gone: xxd does that, as examples/elf already does it, and the license header it also wrote is a template beside it. fdpic-verify.sh and nuttx-exports.sh are gone with no replacement; they checked at build time what the xipfs suite already asserts at run time, for two hundred lines. What the fixtures no longer carry is a crt0 and a linker script. Both come from the tree named by NUTTX_DIR, which is where the in-tree module build takes them, so a fixture is built the way a module is. The crt0 source is compiled here rather than the built object taken, because these are deliberately built for cortex-m3 while the firmware is not: a v7-M module runs on both the v7-M and v8-M targets, so one set of headers serves the RP2350 and mps2-an500 alike. Regenerated qsorter, libshape and cxxuser against a tree configured with CONFIG_FDPIC. qsorter is ARM FDPIC, v7-M, two PT_LOAD segments, entering at _start; libshape carries its SONAME and its DT_INIT_ARRAY. The committed headers are left as they are. They will change when they are next regenerated, because a fixture now carries the tree's crt0 rather than one of its own, and that is a change the xipfs suite should be run against rather than made blind. Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>

github-actions · 2026-08-28T22:10:54Z