Make Xtensa linker scripts compatible with rust-lld by MabezDev · Pull Request #5582 · esp-rs/esp-hal

MabezDev · 2026-05-17T13:02:01Z

Pure claude work here, but verified by building various examples. The rest of this PR body is claude, but interesting if you want to understand the changes.

GNU ld and LLD interpret bare . = <const> assignments inside an output
section differently — GNU ld treats them as section-relative offsets,
LLD treats them as absolute addresses. The .vectors section in the
exception template relied on the section-relative behaviour, and the
combined *(.literal .text .literal.* .text.*) patterns relied on GNU
ld's pattern-order section sorting, which LLD does not perform.

Rework .vectors to use SUBALIGN(0x40) plus relative . = . + N
padding so the vector slot positions are derived from input section
sizes rather than absolute assignments, and split the combined
literal/text patterns into separate clauses so literals are always
emitted before the code that references them (required because Xtensa
L32R can only address literals at negative PC offsets).

Changelog

esp-hal

Fixed: Xtensa LLD can now link projects again, as long as they don't have GCC linked libraries. Support for linking via LLD with GCC binaries will be possible once [lld][Xtensa] Apply the in-place addend for R_XTENSA_32 espressif/llvm-project#130 lands and is included in the esp toolchain.

xtensa-lx-rt

No changelog necessary.

Copilot

Pull request overview

Makes the Xtensa linker scripts work with both GNU ld and rust-lld by removing semantics that differ between the two: bare . = <const> assignments inside output sections (interpreted as section-relative by GNU ld but absolute by LLD) and combined .literal .text patterns whose ordering depended on GNU ld's pattern-position sorting.

Changes:

Rewrite .vectors to use SUBALIGN(0x40) and relative . = . + 0x40 padding so vector slots fall at architecturally fixed offsets under both linkers.
Split combined *(.literal .text ...) patterns into separate literal-first / text-after clauses so Xtensa L32R (literals must precede code) is satisfied regardless of pattern-position vs input-order sorting.
Add per-archive selectors for GCC-built blobs (wifi/phy/bt) in text.x so each archive's per-function literal/text pairs stay grouped together and within the 256 KB L32R reach.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
xtensa-lx-rt/exception-esp32.x.template	Replace absolute `. = 0xNN` slot assignments with `SUBALIGN(0x40)` + `. = . + 0x40` gap before DoubleExceptionVector.
xtensa-lx-rt/xtensa.in.x	Split combined `.literal .text` patterns in `.text` and `.rwtext` into literal-first/text-after clauses.
esp-hal/ld/sections/text.x	Add per-archive selectors for GCC blobs (wifi/phy/bt); split catch-all into separate literal/text clauses.
esp-hal/ld/sections/rwtext.x	Split `.rwtext` literal/text patterns; also split the `esp_rom_spiflash.*` selector.
esp-hal/ld/sections/rtc_slow.x	Split `.rtc_slow` literal/text patterns.
esp-hal/ld/sections/rtc_fast.x	Split `.rtc_fast` literal/text patterns.

MabezDev · 2026-05-17T13:04:42Z

 SECTIONS {

-  .vectors :
+  .vectors : SUBALIGN(0x40)


Literally would have never found this by myself, makes what we want to do here a lot easier!

bugadani · 2026-05-17T13:45:14Z

CI looks like we don't get away with only this much

MabezDev · 2026-05-17T13:59:33Z

CI looks like we don't get away with only this much

Working on it :D

Copilot

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

MabezDev · 2026-05-20T14:48:31Z

Whilst CI passes, I think we should do some more thorough testing (mostly with GCC) to ensure this doesn't break tonnes of stuff.

Copilot

Copilot wasn't able to review this pull request because it exceeds the maximum number of lines (20,000). Try reducing the number of changed lines and requesting a review from Copilot again.

MabezDev · 2026-05-29T09:51:46Z

/hil full

github-actions · 2026-05-29T09:52:56Z

Triggered full HIL run for #5582.

Run: https://github.com/esp-rs/esp-hal/actions/runs/26630574679

Status update: HIL (full) run is still in progress or status unknown.

Copilot

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

github-actions · 2026-05-29T18:49:07Z

New commits in main have made this PR unmergeable. Please resolve the conflicts.

GNU ld and LLD interpret bare `. = <const>` assignments inside an output section differently — GNU ld treats them as section-relative offsets, LLD treats them as absolute addresses. The `.vectors` section in the exception template relied on the section-relative behaviour, and the combined `*(.literal .text .literal.* .text.*)` patterns relied on GNU ld's pattern-order section sorting, which LLD does not perform. Rework `.vectors` to use SUBALIGN(0x40) plus relative `. = . + N` padding so the vector slot positions are derived from input section sizes rather than absolute assignments, and split the combined literal/text patterns into separate clauses so literals are always emitted before the code that references them (required because Xtensa L32R can only address literals at negative PC offsets). The resulting binaries flash to the same load addresses and produce the same number of esptool segments under both linkers.

With the previous split `*(.literal .literal.*) *(.text .text.*)`, every literal pool across every archive was emitted before any code, so once the wifi/BT blobs were linked the per-function `.literal.<f>` pools ended up >256 KB from their own `.text.<f>` — past the L32R PC-relative range — and the link failed with `R_XTENSA_SLOT0_OP out of range`. Pull each Espressif archive in as its own block using the combined `(.literal .text .literal.* .text.*)` pattern. Both GNU ld and LLD preserve input-file order within a single pattern group, so GCC's per-function literal/text pairs stay adjacent and every L32R inside an archive resolves regardless of total image size. The catch-all keeps the split form because rustc's Xtensa backend emits its `.literal` after the function `.text.*` sections in each object. LLD- and GCC-linked images of a minimal embassy_net + esp-radio app are now byte-structure identical (same 6 esptool segments, same load addresses, same sizes).

The split catch-all bunched all literals at the start of .text, pushing late code past the 256 KB L32R window in large (radio) images. Use a combined `*(...)` group so each function's literal pool stays adjacent to its code, and pull the boot code's bare `.literal` pool and its two consumers (`__pre_init` / `__post_init`) to the front so their L32R loads stay in reach regardless of image size.

Copilot AI review requested due to automatic review settings May 17, 2026 13:02

Copilot started reviewing on behalf of MabezDev May 17, 2026 13:02 View session

Copilot AI reviewed May 17, 2026

View reviewed changes

MabezDev commented May 17, 2026

View reviewed changes

Copilot AI review requested due to automatic review settings May 17, 2026 14:17

Copilot started reviewing on behalf of MabezDev May 17, 2026 14:17 View session

Copilot AI reviewed May 17, 2026

View reviewed changes

Comment thread xtensa-lx-rt/exception-esp32.x.template

Copilot AI review requested due to automatic review settings May 29, 2026 09:18

Copilot AI reviewed May 29, 2026

View reviewed changes

MabezDev force-pushed the xtensa-lld-support branch from cc8ddb4 to 4f6d6f3 Compare May 29, 2026 09:19

Copilot AI review requested due to automatic review settings May 29, 2026 10:04

Copilot started reviewing on behalf of MabezDev May 29, 2026 10:04 View session

Copilot AI reviewed May 29, 2026

View reviewed changes

github-actions Bot added the merge-conflict Merge conflict detected. Automatically added/removed by CI. label May 29, 2026

MabezDev added 4 commits May 29, 2026 20:34

CI: verify Xtensa examples link with LLD

fe3d74f

MabezDev force-pushed the xtensa-lld-support branch from 72af832 to cda5f74 Compare May 29, 2026 19:39

github-actions Bot removed the merge-conflict Merge conflict detected. Automatically added/removed by CI. label May 29, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make Xtensa linker scripts compatible with rust-lld#5582

Make Xtensa linker scripts compatible with rust-lld#5582
MabezDev wants to merge 4 commits into
mainfrom
xtensa-lld-support

MabezDev commented May 17, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

MabezDev May 17, 2026

Uh oh!

bugadani commented May 17, 2026 •

edited by MabezDev

Loading

Uh oh!

MabezDev commented May 17, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

MabezDev commented May 20, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

MabezDev commented May 29, 2026

Uh oh!

github-actions Bot commented May 29, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

github-actions Bot commented May 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

MabezDev commented May 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changelog

esp-hal

xtensa-lx-rt

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

MabezDev May 17, 2026

Choose a reason for hiding this comment

Uh oh!

bugadani commented May 17, 2026 • edited by MabezDev Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MabezDev commented May 17, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

MabezDev commented May 20, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

MabezDev commented May 29, 2026

Uh oh!

github-actions Bot commented May 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

github-actions Bot commented May 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

MabezDev commented May 17, 2026 •

edited

Loading

bugadani commented May 17, 2026 •

edited by MabezDev

Loading

github-actions Bot commented May 29, 2026 •

edited

Loading