tools/ci: Add the FDPIC binutils to the Linux CI image.

[casaroli]

Summary

FDPIC modules cannot be built anywhere CI can reach, because the linker they need is not packaged by any distribution. This adds it to the Linux CI image so that the FDPIC module build can be integrated into the normal in-tree ELF build rather than living in a separate out-of-tree toolchain, which is what was asked for in the review of #19940.

An FDPIC module is compiled by the stock arm-none-eabi GCC, which emits correct FDPIC objects for both C and C++. What that toolchain cannot do is assemble or link them: its as rejects the FDPIC relocations, and its ld is configured with the armelf emulation alone.

Linking FDPIC objects with the stock ld anyway does not fail, which is the awkward part. It produces an object marked UNIX - System V instead of ARM FDPIC, and turns every import into an R_ARM_JUMP_SLOT where the ABI wants an R_ARM_FUNCDESC_VALUE. A jump slot is one word and a descriptor is two, a code address and the GOT that goes with it, so such a module links cleanly and then calls out of itself with the caller's data base still in the PIC register.

So the image builds arm-uclinuxfdpiceabi binutils in its own stage, the way the Renesas stage already builds its own binutils. Only binutils is needed, no GCC and no C library.

The tarball comes from sourceware.org, the binutils project's own host, because ftp.gnu.org is not reliably reachable from every builder. curl runs with --fail so a bad fetch says so, rather than piping an error page into tar and failing as File format not recognized, which is what happened while writing this.

Impact

Build infrastructure only. No target code, no configuration, no documentation.

The image grows by 20 MB, stripped, and the stage takes about 35 seconds. For scale, gcc-arm-none-eabi in the same image is several hundred megabytes.

Nothing in the tree uses the new toolchain yet. It is a prerequisite for the FDPIC module build, which follows.

Testing

Host: macOS 15 on Apple Silicon, Docker 29.4.0.

The stage was built on its own and the result exercised in a container.

The linker carries the emulation that the stock one does not:

$ docker run --rm nuttx-fdpic-binutils arm-uclinuxfdpiceabi-ld -V
GNU ld (GNU Binutils) 2.43
  Supported emulations:
   armelf_linux_eabi
   armelfb_linux_eabi
   armelf_linux_fdpiceabi
   armelfb_linux_fdpiceabi

against the stock toolchain, which is the failure this exists to prevent:

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

Linking a C++ module inside the container, one with a static global object, gives a correct FDPIC shared object:

OS/ABI:                            ARM FDPIC
Type:                              DYN (Shared object file)
Entry point address:               0x2b9
FUNCDESC relocations: 3
 0x00000019 (INIT_ARRAY)                 0x1328
 0x0000001b (INIT_ARRAYSZ)               4 (bytes)

The same objects linked with the stock arm-none-eabi-ld link without error and produce OS/ABI: UNIX - System V with three R_ARM_JUMP_SLOT entries instead, which is the silent breakage described above.

Installed size in the image:

$ docker run --rm nuttx-fdpic-binutils du -sh /tools/binutils-arm-uclinuxfdpiceabi
20M	/tools/binutils-arm-uclinuxfdpiceabi

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