boards/rp23xx: copy .got into RAM at boot in the memmap linker scripts#19401
Merged
Conversation
The pico-sdk-derived rp23xx linker scripts place .got/.got.plt as orphan
sections after the .data output section, so the boot-time .data copy
(which runs to _edata) never copies the GOT into RAM. Any position-
independent (-fPIC) object linked into an application then reads an
uninitialised GOT full of NULLs: the first GOT-indirected access
branches to 0 and the board hardfaults before main(). A PIC static
library (for example liboqs, whose SHA3 dispatch reads its function
pointers through the GOT) triggers this deterministically.
Fold *(.got)/*(.got.plt) into the .data{} section, before _edata, in all
three boot-mode scripts (memmap_default/copy_to_ram/no_flash) for every
rp23xx board, so the GOT is initialised in RAM by the standard startup
copy. No effect on non-PIC images (the GOT is empty).
Reproduced and fixed on a Raspberry Pi Pico 2 W: an app linking a -fPIC
liboqs.a wedged the board on its first crypto call before the change and
runs correctly after it.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Ricard Rosson <ricard@groundbits.com>
xiaoxiang781216
approved these changes
Jul 11, 2026
github-actions
Bot
added
Size: S
|
acassis
approved these changes
Jul 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The pico-sdk-derived rp23xx linker scripts place
.got/.got.pltas orphansections after the
.dataoutput section, so the boot-time.datacopy —which runs to
_edata— never copies the GOT into RAM. Any position-independent(
-fPIC) object linked into an application then reads an uninitialised GOT fullof NULLs: the first GOT-indirected access branches to 0 and the board hardfaults
before
main().This is not hypothetical — a
-fPICstatic library is enough. In my case a NuttXapp linking a
-fPICliboqs.a(whose SHA3 dispatch reads its function pointersthrough the GOT) wedged the board deterministically on its first crypto call.
The fix folds
*(.got)/*(.got.plt)into the.data{}section, before_edata,in all three boot-mode scripts (
memmap_default/memmap_copy_to_ram/memmap_no_flash) for every rp23xx board, so the GOT is initialised in RAM by thestandard startup copy.
Impact
-fPIClibrary linked into an rp23xx app.zero bytes.
raspberrypi-pico-2,xiao-rp2350andpimoroni-pico-2-plus.Testing
Reproduced and fixed on a Raspberry Pi Pico 2 W. With the original scripts, an app
linking a
-fPICliboqs.ahardfaulted on its first hardware crypto call (tracedto a NULL GOT-indirected dispatch pointer; the ELF showed
.gotlanding exactly at_edata, i.e. outside the copied range). After folding.gotinto.data, theGOT is populated in RAM and the same app runs correctly.
Disclosure: this change was prepared by an AI agent (Claude Code) at the direction
of the author, who root-caused and tested it on hardware before submission.
🤖 Generated with Claude Code