casaroli opened a new pull request, #20377: URL: https://github.com/apache/nuttx/pull/20377
## Summary `ldnxflat` is the last part of the NXFLAT toolchain that NuttX cannot carry, and this adds an Apache-2.0 replacement for it. `mknxflat` came into the tree in #19600 and was relicensed with its author's agreement, because Gregory Nutt owned all of it. `ldnxflat` cannot follow. It descends from `elf2flt` and `obj-res.c` through eleven sets of copyright holders reaching back to 1996, several of them companies that no longer exist, so it is GPL by descent rather than merely by its `libbfd` dependency, and no set of permissions can be assembled. A board that builds NXFLAT modules therefore has to fetch a GPL tool from buildroot today. Four commits: `arch/arm: Reach an NXFLAT module's read-only data through the GOT.` An NXFLAT module's D-Space is allocated apart from its I-Space, so its read-only data is not at a fixed offset from its text. GCC assumes it is and reaches a string literal with a PC-relative load, which at run time reads I-Space. `gnu-nxflat-gotoff.ld` has always said the model reaches read-only data through the GOT; `-mno-pic-data-is-text-relative` is what makes the compiler agree. This is why a module "could not carry a string". `tools/nxflat: Add a driver for the NXFLAT test suite.` Building a module takes four tools in sequence and there was no way to exercise them without a board. `testsuite.sh` builds every module of `apps/examples/nxflat/tests` for cortex-m3 against a configured tree's headers and reports, per module, where it stopped and which relocations it carried. With `LDNXFLAT_REF` naming a second converter it converts each module twice and compares. `tools/nxflat: Add an Apache-licensed NXFLAT converter.` The relocation arithmetic is NuttX's own, from `libs/libc/machine/arm/armv7-m/arch_elf.c`, which is the code the ELF loader runs on the target for the same relocations. Reusing it costs nothing and buys `R_ARM_TARGET1`, which the out-of-tree tool refuses. NXFLAT is not an ARM format — `binfmt/Kconfig` puts no architecture dependency on it and the loader only ever adds a base to a 32-bit word — so an architecture supplies a table entry, an entry-point convention and a relocation handler, and an object for an unknown machine is refused by name instead of converted wrongly. `tools/nxflat: Read the object in one place.` Both tools parsed ELF32 with their own copies, and disagreed about byte order: one swapped every field against the host, the other refused anything not little endian. `nxflat_elf.c` now reads the object for both. ## Impact Nothing changes for a configuration that does not set `CONFIG_NXFLAT`. For one that does, `LDNXFLAT` now names the tool in the tree rather than looking for one on `PATH`, and `NXFLAT_TOOL_DEP` builds it beside `mknxflat`. `mknxflat`'s output is unchanged: the thunk it generates for each of the eleven test modules is byte identical to the one the merged version generates. Two defects of the out-of-tree tool do not survive the rewrite. A GOT entry naming a `.bss` object was resolved without its section's address, so it pointed at the start of D-Space — the GOT itself — and a module that reached a static through the GOT read and wrote its own GOT. The alignment gap between `.data` and `.bss` also went missing from `h_bssend`, leaving D-Space short. `-d` goes from both tools. It selected a dynamic symbol table, which the `ld -r` object these tools convert does not have, and which the NXFLAT loader has no notion of: imports reach a module through the array `mknxflat` generates. NuttX does read `.dynsym`, in `libs/libc/elf` for `ET_DYN` objects, but nothing in this path can. ## Testing `tools/nxflat/testsuite.sh` over `apps/examples/nxflat/tests`, with the out-of-tree tool as the reference: ``` SAME errno hello hello++1 hello++2 pthread struct BETTER hello++3 the reference: "Do not know how to handle reloc 38 type R_ARM_TARGET1" EXPECTED longjmp mutex signal task COMPILE hello++4 needs an iostream, not a tool problem ``` Six modules byte identical, one converted where the reference gives up, four differing only where the reference is wrong. For `mutex`: `.LANCHOR0` is `st_value` 0 in `.bss`, whose `sh_addr` is `0x194`, and the GOT is `0x34` long, so the entry must hold `0x1c8`; the reference writes `0x34`. `lm3s6965-ek:qemu-nxflat` under `qemu-system-arm -M lm3s6965evb`, with the eight C modules of the suite in its ROMFS, runs every one of them to `End-of-Test.. Exit-ing`, including `main: SUCCESS: setjmp return from longjmp call` and `struct`'s `pf = 0x13335` — odd, so the Thumb bit survives — followed by `In dummyfunc() -- PASS`. Built with the out-of-tree tool instead, the same image panics in the third test with `PC: 00000000` and the remaining five never run. `tools/checkpatch.sh -c -u -m -g` passes. ## Provenance The container is defined by `include/nxflat.h` and by what `binfmt/libnxflat` does with it, the segment layout by `gnu-nxflat-gotoff.ld`, and the relocation arithmetic is that of `arch_elf.c`. Those files and the new one are Apache-2.0. No part of the out-of-tree tool is used. It was run on the same inputs to compare output against, which is how the conventions the container does not state — where the GOT sits, the order of its entries, the order of the relocation records — were matched. Two of its results are deliberately not matched, because they are wrong, and the file says which. Its option set is not inherited either: the entry point and the output name are required rather than guessed, because every board that builds a module already gives both. ## Review `apache/nuttx-apps#PENDING` builds the test modules this exercises; it is not needed for this one to be correct. The converter is new in its entirety, so it may read more easily beside `include/nxflat.h` and `binfmt/libnxflat/libnxflat_bind.c` than on its own. -- 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]
