ld: add custom linker script for ARM targets

[rmikielis]

Description

Attempt to create custom linker script template for kernel. Firstly for ARM targets, and if accepted next architectures will be added.

Motivation and Context

This allows to control output .elf sections (moving syspage out of .bss) and to unify symbols definitions across all platforms (ex. the same bss_start/end symbols allowing for generic .bss clearing function)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (refactoring, style fixes, git/CI config, submodule management, no code logic changes)

How Has This Been Tested?

• Already covered by automatic testing.
• New test added: (add PR link here).
• Tested by hand on: (armv8r52-mps3an536-qemu).

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing linter checks and tests passed.
• My changes generate no new compilation warnings for any of the targets.

Special treatment

• This PR needs additional PRs to work (list the PRs, preferably in merge-order).
• I will merge this PR by myself when appropriate.

[gemini-code-assist]

Hello @rmikielis, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

Summary of Changes

Hello! Gemini here, providing a summary of this pull request. This PR introduces a new approach for managing linker scripts by adding support for target-specific linker script templates (.ldt) that are processed by the C preprocessor. The initial implementation focuses on the armv8r52-mps3an536 target, providing a custom script that defines memory regions and section placement, including placing the .syspage section separately within the BSS region and defining unified BSS symbols.

Highlights

• Custom Linker Scripts via Templates: This pull request transitions from extracting a default linker script via ld --verbose to using custom linker script templates (.ldt) that are processed by the C preprocessor. This allows for more flexible and maintainable linker script definitions, including using C-style includes and preprocessor directives.
• Target: armv8r52-mps3an536: A new target-specific linker script template, ld/armv8r52-mps3an536.ldt, is added. This script defines the memory map for the target, including ATCM, BRAM, and DDR regions, and sets up region aliases for KERNEL_IMAGE, DATA, and BSS pointing to the BRAM region.
• Common ARM Kernel Script: A new common linker script, ld/common/kernel-arm.lds, is introduced. This script defines the standard sections for an ARM kernel (e.g., .init, .text, .rodata, .data, .bss, .syspage, .noinit) and provides unified symbols for section boundaries (like __bss_start and __bss_end), addressing the motivation of standardizing symbol definitions across platforms.
• Build System Integration: The Makefile is updated to use the new .ldt template system. It defines an LDGEN variable (defaulting to $(CC)) to preprocess the .ldt file into the final .ld script used by the linker. The old method of parsing ld --verbose output is removed.
• Section Placement: The new linker script explicitly defines the placement of various sections. Notably, the .syspage section is given its own entry within the BSS region, separate from the main .bss section, fulfilling one of the stated motivations.

Changelog

Click here to see the changelog

• Makefile
  • Added LDGEN ?= $(CC) to allow specifying the linker script preprocessor.
  • Updated the ELF target dependency from .ldt to the generated .ld file.
  • Removed the rule that extracted the default linker script using ld --verbose and sed.
  • Added a new rule to generate the target-specific .ld file from the .ldt template using $(LDGEN) with C preprocessor flags (-E -P, -D__LINKER__, etc.).
  • Included dependency generation and cleanup for the generated .ld file.
• ld/armv8r52-mps3an536.ldt
  • New file added.
  • Defines memory addresses and sizes for ATCM, BRAM, and DDR.
  • Defines platform-specific sizes for page, stack, heap, and kernel area.
  • Uses #if defined(__LINKER__) guard for linker-specific content.
  • Defines the m_bram memory region.
  • Defines REGION_ALIAS for KERNEL_IMAGE, DATA, and BSS pointing to m_bram.
  • Includes the common ARM kernel linker script (common/kernel-arm.lds).
• ld/common/kernel-arm.lds
  • New file added.
  • Specifies ELF output format and ARM architecture.
  • Sets the entry point to _start.
  • Defines standard kernel sections: .init, .text, .fini, .rodata, .ARM.exidx, .data, .persistent, .bss, .syspage, .noinit.
  • Defines unified symbols for section boundaries (e.g., __init_start, __text_start, __data_start, __bss_start, __bss_end, _end).
  • Includes .ARM.attributes section.
  • Includes a /DISCARD/ section for unwanted content.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

---

Linker script, a map so grand,
Sections placed by skilled command.
Text, data, bss,
Ordered, no mess,
Code finds its home across the land.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

The pull request introduces a custom linker script for the armv8r52-mps3an536 target, aiming to control .elf sections and unify symbol definitions. The changes seem well-structured, but there are a few points that could be improved for clarity and maintainability.

Summary of Findings

• Incorrect endif comment: The endif comment at the end of ld/armv8r52-mps3an536.ldt references the wrong macro. This should be corrected for clarity.
• syspage placement: The .syspage section is currently placed in the BSS region. Verify if this is the intended behavior, and if not, adjust the memory map accordingly.
• Makefile sed command: The sed command in the Makefile could benefit from a comment explaining its purpose.

Merge Readiness

The pull request introduces important changes for the target platform. However, the incorrect endif comment and the placement of the .syspage section should be addressed before merging. I am unable to approve this pull request, and recommend that others review and approve this code before merging. At a minimum, the high severity issue should be addressed before merging.

[agkaminski]

This is a brain child of our discussions, so I of course like the idea :)

Perhaps we could remove some stuff from the phoenix-rtos-build then (I mean e.g. -Tbss=10014000 -Tdata=10014000). Would be nice.

Note that tin can's remarks seem valid.

[rmikielis]

Config files for the rest of ARM targets will be added one by one when time allows