Feature request: add a machine-readable linker JSON export to GNU Tools for STM32 ld

[shpegun60]

Summary

I would like to propose adding a machine-readable JSON export to the ld linker shipped in GNU Tools for STM32.

The goal is to make the final linker state available in a structured form, instead of requiring downstream tooling to parse .map files or linker console output.

Motivation

Today, many linker-related analyses depend on text parsing of map files. That works, but it is fragile and hard to evolve.

A structured JSON export would make it much easier to:

• inspect the final linker layout programmatically
• analyze memory regions and output sections
• track placed and discarded input sections
• inspect linker-visible symbols
• build validation, regression, and visualization tools around the linker result
• compare toolchain revisions and linker-script changes in a reliable way

Proposed output scope

A useful minimal JSON contract would expose linker state such as:

• format
• output
• memory_regions
• output_sections
• input_sections
• discarded_input_sections
• symbols

This would allow tools to consume stable structured data instead of reverse-parsing map output.

Reference implementation

I built a working prototype patcher around ST gnu-tools-for-stm32 source packages and verified it locally on:

• 13.3.rel1
• 14.3.rel1

The prototype patches src/binutils/ld, rebuilds the linker, verifies the produced JSON, and packages the result for STM32CubeIDE-style use.

Repository:

• https://github.com/shpegun60/ld_patcher

README:

• https://github.com/shpegun60/ld_patcher#readme

Supported source packages used for validation:

• https://github.com/STMicroelectronics/gnu-tools-for-stm32/archive/refs/tags/13.3.rel1.zip
• https://github.com/STMicroelectronics/gnu-tools-for-stm32/archive/refs/tags/14.3.rel1.zip

What the prototype does

At a high level, the prototype:

• adds JSON implementation code into src/binutils/ld
• extends linker option handling
• injects the runtime hook after final linker layout is known
• emits structured JSON for the resolved link state
• validates the produced output with a self-contained smoke test

Why this may be useful for ST

This could help make STM32CubeIDE and ST toolchain integrations more observable and easier to automate.

Possible use cases include:

• internal tooling
• diagnostics
• linker visualization
• regression testing
• ecosystem integrations around STM32CubeIDE and gnu-tools-for-stm32

Request

Would ST be open to discussing or evaluating support for an official JSON export mode in the STM32 GNU linker fork?

Even feedback on whether this is interesting, out of scope, or better handled another way would already be very useful.