examples/fdpicxip: Build the module fixtures without nuttx/tools/fdpic.

[casaroli]

depends-on: [apache/nuttx/pull/19940]

Summary

The FDPIC modules this example and testing/fs/xipfs carry are built by an explicit make regen, which reached into nuttx/tools/fdpic for a makefile, a script that turned a module 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 module is built by apps/Application.mk like any other. What these fixtures need comes here instead, and it is much less.

They keep a build at all because they are loader edge cases, not ordinary modules: 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 -soname, or "no entry point", or "link against that other module".

What arrives is 145 changed lines in the makefile that was already here, plus a 24-line license template. What does not arrive is four files and 536 lines:

• the generic module makefile, which existed to be included by anything and was only ever included here
• fdpic-embed.py, because xxd -i does that and examples/elf already uses it that way
• fdpic-verify.sh and nuttx-exports.sh, with no replacement: they checked at build time what the xipfs suite already asserts at run time

The fixtures also stop carrying a crt0 and a linker script. Both come from the tree named by NUTTX_DIR, which is where the in-tree build takes them. 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 v7-M and v8-M targets, so one set of headers serves the RP2350 and mps2-an500 alike.

Impact

None on any build. make regen is not part of the application build and nothing else runs these files. The *_bin.h headers stay committed, so both apps still build with a plain toolchain and no FDPIC linker.

NUTTX_DIR now has to be configured with CONFIG_FDPIC, because that is what puts the FDPIC segments in the generated gnu-elf.ld.

The committed headers are unchanged here. They will change when 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.

Testing

Rebuilt three fixtures from clean against a tree configured with CONFIG_FDPIC, covering both kinds and both languages: qsorter (C module), libshape (C++ library) and cxxuser (C++ module linked against it).

$ readelf -h qsorter.fdpic
  OS/ABI:      ARM FDPIC
  Entry point: 0x1              <- _start, from the tree's crt0
$ readelf -A qsorter.fdpic
  Tag_CPU_arch: v7
$ readelf -d libshape.fdpic
  0x0e (SONAME)      Library soname: [libshape.so]
  0x19 (INIT_ARRAY)  0x1000

Two PT_LOAD segments, and v7-M as intended rather than the firmware's v8-M.

callback is the one fixture not rebuilt here: it uses SIGEV_THREAD, so it needs a tree with CONFIG_SIG_EVTHREAD.

tools/checkpatch.sh -c -u -m -g passes.

[github-actions]

🔗 Cross-repo PR dependencies

The read-only Build run reported the following dependent PR(s) and fetched head SHA(s):

• [5.5/10] arch/arm, cmake: Build FDPIC modules in the normal ELF build. nuttx#19940 @ c08569ce6e

CI run: https://github.com/apache/nuttx-apps/actions/runs/33193062300