casaroli opened a new pull request, #19673: URL: https://github.com/apache/nuttx/pull/19673
## Summary Loads ELF shared objects built for the ARM FDPIC ABI, as a mode of the existing ELF loader rather than as a separate binary format. An FDPIC object places its two `PT_LOAD` segments independently, so its read-only segment is executed straight out of flash where the filesystem already holds it, and only the writable segment is copied to RAM, once per running instance. Several instances of one module therefore share one copy of the text. What FDPIC adds over the position independent ELF support already present is a function pointer that carries its own data base, as a two word descriptor rather than a bare code address; that is what lets a module be called back on a thread it did not create, such as the work queue worker that runs a `SIGEV_THREAD` notification. This supersedes #19584, which added a separate `binfmt/fdpic.c`. Everything is folded into `libs/libc/elf` and `binfmt/elf.c` instead, and `DT_NEEDED` is implemented by calling `dlopen()`, as requested in that review. Depends-on: #19600 (r9 as the PIC base register), whose three commits are included here. Paired with apache/nuttx-apps#PENDING, which updates the two test apps that are already upstream. ## Semantics worth reviewing A library named in `DT_NEEDED` is opened with `dlopen()`, which returns the object already in the module registry rather than loading a second copy. There is therefore one instance of a library, its data included, shared by every module that names it. A module started with `exec()` is different: that path loads the module afresh each time, so two running instances have separate data while sharing one copy of the text. `apps/testing/fs/xipfs` and `apps/examples/fdpicxip` asserted the opposite, because the loader that walked `DT_NEEDED` itself gave each instance a private copy. The paired apps PR updates them. ## Testing `apps/testing/fs/xipfs` and `apps/examples/fdpicxip` are already upstream and carry the assertions; both were run in full. QEMU, `mps2-an500` (Cortex-M7, xipfs on a rammtd that answers `XIPFSIOC_PIN`): ``` 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 ``` Hardware, Pimoroni Pico Plus 2 (RP2350, Cortex-M33, real QSPI flash), same numbers: 131/131, 34/34, 7/7 and all four demos. That covers the armv8-m relocation path and a filesystem that really pins extents. Between them these reach `R_ARM_FUNCDESC` and the descriptor pool, all ten libc and sched callback entry points, `SIGEV_THREAD` delivery through `mq_notify()` and `timer_create()`, `DT_JMPREL` binding, `XIPFSIOC_PIN`, two modules sharing one library, C++ modules with constructors in dependency order, and the six rejection cases. `CONFIG_ELF_STACKSIZE` wants 4096 for these modules: 2048 overflows on a module that calls into the firmware's printf family, and with no MPU that is a lockup rather than a diagnostic. -- 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]
