casaroli opened a new pull request, #3762:
URL: https://github.com/apache/nuttx-apps/pull/3762
depends-on: [apache/nuttx/pull/19940]
## Summary
The FDPIC modules this example and `testing/fs/xipfs` carry are built by an
explicit `make regen`, and that reached into `nuttx/tools/fdpic` for the
makefile that builds a module and the script that turns one into a header.
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. So `nuttx/tools/fdpic` is going
away, and what these fixtures need comes here instead.
These are not ordinary modules, which is why they keep a build of their own.
They are fixtures for loader edge cases: a shared 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 that names a symbol the
firmware does not export, which exists to be refused. `Application.mk` has no
way to say `-soname`, or "no entry point", or "link against this other module",
so the fixtures keep their own makefile, and it belongs beside them rather than
in NuttX.
What they no longer keep is a `crt0` and a linker script. Both now 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.
## 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 a tree configured with `CONFIG_FDPIC`, because
that is what puts the FDPIC segments in the generated `gnu-elf.ld`. It already
had to be a configured, built tree.
## Testing
Host: macOS 15 on Apple Silicon, Arm GNU Toolchain 15.3.Rel1 for the
compiler and `arm-uclinuxfdpiceabi` binutils 2.43 for the link.
Rebuilt two fixtures against a tree configured with `CONFIG_FDPIC`, one of
each kind.
A module:
```
$ readelf -h qsorter.fdpic
OS/ABI: ARM FDPIC
Type: DYN (Shared object file)
Entry point: 0x1 <- _start, from the tree's crt0
$ readelf -A qsorter.fdpic
Tag_CPU_arch: v7
Tag_CPU_arch_profile: Microcontroller
```
two `PT_LOAD` segments, and v7-M as intended rather than the firmware's v8-M.
A library:
```
$ readelf -h libshape.fdpic
OS/ABI: ARM FDPIC
Entry point: 0x0
$ readelf -d libshape.fdpic
0x0e (SONAME) Library soname: [libshape.so]
0x19 (INIT_ARRAY) 0x1000
```
`tools/checkpatch.sh -c -u -m -g` passes.
--
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]
