examples/fdpicxip, testing/fs/xipfs: A DT_NEEDED library is one instance

[casaroli]

Summary

examples/fdpicxip and testing/fs/xipfs assert that each running instance of a module gets its own copy of a library named in DT_NEEDED: two instances adding their own seed each saw a total of seed * 3.

That was true of the loader that walked DT_NEEDED itself. The loader now hands the work to dlopen(), which returns the object already in the module registry rather than loading a second copy, so there is one library and one set of its globals, shared by every module that names it. The module's own data stays private per instance, because exec() loads the module afresh each time.

What an instance can still assert on its own is that every add it made landed in the library, so that is what it checks. The test additionally checks the consequences: the library is pinned once rather than once per instance, and its destructor runs once, at the last close, holding what both instances built up.

The embedded module blobs are regenerated from the sources beside them.

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

Testing

Run in full on QEMU mps2-an500 and on a Pimoroni Pico Plus 2 (RP2350), against apache/nuttx#19673.

xipfs_test          131 passed, 0 failed
xipfs_test fdpic     34 passed, 0 failed
xipfs_test reject     7 passed, 0 failed
fdpicxip qsort | solib | cxx | jmprel

[xiaoxiang781216]

could we integrate fdpic special process into the post link after you corporate fdpic into elf binfmt?

[casaroli]

for building fdpic modules, we can do with stock gcc, however for linking them we need upstream binutils rebuilt with arm-uclinuxfdpiceabi-ld, as stock arm ld does not ship with it:

$ arm-none-eabi-ld -V
GNU ld (Arm GNU Toolchain 15.2.Rel1) 2.45.1
  Supported emulations:
   armelf

What do you suggest? can we include the "custom" binutils in the CI image?