modlib: preprocess gnu-elf.ld for executable ELF

[yf13]

Summary

This allows apps for kernel mode NuttX (e.g. on arm/qemu-armv7a) can be built as executable type ELF files. Benefits of executable programs are smaller in size and easier GDB debugging.

Initial scope was only for qemu-armv7a but it used an almost duplicated gnu-elf.ld which differs only at .text and .data addresses from the gnu-elf.ld in modlib.

To avoid such duplications, a preprocessed gnu-elf.ld in modlib is added so that to adapt to target config. This requires minor tweaks for addrenv.h so that some macros can be included in gnu-elf.ld.in.

Impacts

Hardware: qemu-armv7a or using kernel build.

Testing

• local checks with QEMU v6.2 on Ubuntu 22.04: qemu-armv7a:knsh, bl602evb:elf.
• CI checks

[nuttxpr]

[Experimental Bot, please feedback here]

Yes, this PR appears to meet the basic NuttX requirements, although it could be more thorough. While it addresses the key points, it lacks specific details in several areas which would make review easier.

Here's a breakdown:

Strengths:

• Clear Summary: The summary explains the what and why of the change, and the benefit (smaller size, easier debugging).
• Identifies Impacted Area: Correctly identifies the impact as hardware-specific (qemu-armv7a).
• Mentions Testing: Indicates testing was performed locally and that CI checks are expected.

Weaknesses:

• Missing Detail in Summary: The how is somewhat vague. It states "allows apps... to be built as executable type ELF files," but doesn't explain the mechanism of the change. What was modified to achieve this?
• Impact Lacks Detail: The impact section needs significant expansion. While "qemu-armv7a" is mentioned, it doesn't specify whether other ARM architectures or boards are affected. All other impact categories are simply omitted (user impact, build process, documentation, security, compatibility). These should be explicitly stated as "NO" or "YES" with explanations.
• Insufficient Testing Information: "Local checks" and "CI checks" are too general. The PR needs specific details about the host system (OS version, compiler version). The target information is slightly better but should specify the NuttX configuration used. Most importantly, the "Testing logs before change" and "Testing logs after change" sections are empty. These are crucial for demonstrating the change's effect and should include relevant output showing the difference in behavior.

Recommendation:

The PR author should add the missing details to strengthen it. Specifically:

• Summary: Elaborate on the how. What files were changed? What build system modifications were made?
• Impact: Address all impact categories. Even if the answer is "NO," it should be explicitly stated. For "hardware," be more specific about affected architectures/boards.
• Testing: Provide detailed host and target information. Include actual log output demonstrating the change's effect (e.g., file sizes before/after, GDB debugging experience comparison). If logs are extensive, consider linking to a separate file or using a diff tool.

[xiaoxiang781216]

can we share the same gnu-elf.ld for relacation and exeutable?

[yf13]

Currently the gnu-elf.ld in boards/ folder contains target specific .text address, which is specific to target virtual space design now. If later NuttX kernel build has a unified virtual space design (e.g. kernel at highmem, userspace in lowmem), I believe one userspace gnu-elf.ld will be enough. So maybe we should track unified userspace memory layout separately?

[xiaoxiang781216]

but why not unify the layout now?

[pussuw]

Isn't the linker script board specific data anyway, why must we change (or for that matter, have) anything in the common modlib folder, I don't understand ?

I presume the linker file in the modlib folder is there as an example, not intended for production use in any case.

I question the motivation to have this change at all in upstream.

[xiaoxiang781216]

elf file linker script is different from board linker script, since the layout should be general for all board like how Linux done.

[pussuw]

You are right, the Linux toolchain has a generic linker script, so maybe this change is not as bad as I initially thought. I personally have the gnu-elf.ld file in the board folder for my projects because I still think it is board specific (for now).

[pussuw]

but why not unify the layout now?

Us having a unified virtual address spacing (e.g. user in lowmem, kernel in himem) for now is impossible, as we do not have a good mechanism to move memory mapped devices into the kernel virtual memory area (like fdt and vmap). We have the pieces in place but not a single platform implements this AFAIK ?

This is why I for example configure MPFS the other way around; userspace starts from 0xc000_0000 and kernel resides in the lower part.

I guess this patch does not break this functionality, so I'm fine with it.

[yf13]

Seems that CI is blocked by issue similar to #15441?

[acassis]

Please include a Documentation/ at qemu page showing a usage example

[yf13]

@acassis, the usage is rather simple: just enable BINFMT_ELF_EXECUTABLE config for a kernel build.

Actually this isn't new or specific to QEMU, I used it before for k230 devices, all canmv230 kernel mode have it enable by default, see pull/11513 for the old story.