Handle GOT sections gracefully #3065

2026-07-07T19:55:37-05:00

Prabhuk commented

2026-07-07 19:55:37 -05:00

(Migrated from github.com)

If any of the libraries linked against is built as position independent code, weak undefined symbols and comdat symbols may have GOT relocations. We observed this in the LLVM runtime libraries (libc.a/libm.a) but this behavior is not specific to Clang/LLVM toolchains. Including the GOT sections into the data section to handle them gracefully.

Fixes https://github.com/raspberrypi/pico-sdk/issues/3064

If any of the libraries linked against is built as position independent code, weak undefined symbols and comdat symbols may have GOT relocations. We observed this in the LLVM runtime libraries (libc.a/libm.a) but this behavior is not specific to Clang/LLVM toolchains. Including the GOT sections into the data section to handle them gracefully. Fixes https://github.com/raspberrypi/pico-sdk/issues/3064

petrhosek (Migrated from github.com) reviewed

2026-07-07 19:55:37 -05:00

Prabhuk commented

2026-07-07 19:56:33 -05:00

(Migrated from github.com)

CC: @petrhosek

Prabhuk commented

2026-07-08 18:38:11 -05:00

(Migrated from github.com)

Also tested the gcc build on device. These were the tests I built and ran. Posting the build command for reference

cmake --build build-gcc --target fixed_bitset_test hardware_irq_test hardware_pwm_test hardware_sync_spin_lock_test pico_async_context_test pico_divider_test pico_float_test pico_double_test pico_sem_test pico_sha256_test pico_stdlib_test pico_sync_test_sw pico_thread_local_test pico_time_test pico_stdio_test_uart cmsis_test --parallel

Also tested the gcc build on device. These were the tests I built and ran. Posting the build command for reference ``` cmake --build build-gcc --target fixed_bitset_test hardware_irq_test hardware_pwm_test hardware_sync_spin_lock_test pico_async_context_test pico_divider_test pico_float_test pico_double_test pico_sem_test pico_sha256_test pico_stdlib_test pico_sync_test_sw pico_thread_local_test pico_time_test pico_stdio_test_uart cmsis_test --parallel ```

petrhosek (Migrated from github.com) reviewed

2026-07-08 20:47:46 -05:00

src/rp2_common/pico_standard_link/script_include/section_default_data.incl

					
				@ -30,6 +30,10 @@ SECTIONS

				        *(.data*)

	  /* if linked against non PIC archives, ARM targets may generate dynamic data relocations via got sections */

```suggestion /* if linked against non PIC archives, ARM targets may generate dynamic data relocations via got sections */ ```

petrhosek (Migrated from github.com) reviewed

2026-07-14 16:37:05 -05:00

src/rp2_common/pico_standard_link/script_include/section_default_data.incl

					
				@ -30,6 +30,10 @@ SECTIONS

				        *(.data*)

	    /* if linked against non PIC archives, ARM targets may generate dynamic data relocations via got sections */

```suggestion /* if linked against non PIC archives, ARM targets may generate dynamic data relocations via got sections */ ```

petrhosek (Migrated from github.com) approved these changes

2026-07-14 16:37:22 -05:00

kilograham commented

2026-07-14 17:28:08 -05:00

(Migrated from github.com)

note, i'm not sure this is the right solution - discussion in #3064

Wren6991 commented

2026-08-04 08:02:10 -05:00

(Migrated from github.com)

Noting this is read-write (pulled into .data) -- is the GOT actually being updated at runtime?

If so, that's slightly alarming for an embedded target, but doesn't make the patch incorrect.
If not, should this be in .rodata so we don't allocate RAM for it?

Noting this is read-write (pulled into `.data`) -- is the GOT actually being updated at runtime? * If so, that's slightly alarming for an embedded target, but doesn't make the patch incorrect. * If not, should this be in `.rodata` so we don't allocate RAM for it?

Wren6991 commented

2026-08-04 08:16:57 -05:00

(Migrated from github.com)

Based on reading the upstream LLVM threads, it sounds like a GOT indirection is conservatively emitted, but then the relocation on the GOT entry itself is resolved statically during final link. Is that correct?

kilograham commented

2026-08-06 14:53:47 -05:00

(Migrated from github.com)

note, i think we should still fix this with read-only data probably, but i wonder if these GOT sections are related to tls, and would be fixed via -ftls-model=local-exec anwyay (which we should also add)

note, i think we should still fix this with read-only data probably, but i wonder if these GOT sections are related to tls, and would be fixed via `-ftls-model=local-exec` anwyay (which we should also add)

kilograham commented

2026-08-06 14:55:03 -05:00

(Migrated from github.com)

note peter's claude analysis elsewhere was concerned about .got stuff being in flash when code is in RAM for flash only code... this is a possible wrinkle, but arguably no worse than jump tables (but it would be nice to know where the .got stuff is coming from)

might be a vote for leaving in RAM for now depending

note peter's claude analysis elsewhere was concerned about .got stuff being in flash when code is in RAM for flash only code... this is a possible wrinkle, but arguably no worse than jump tables (but it would be nice to know where the .got stuff is coming from) might be a vote for leaving in RAM for now depending

Wren6991 commented

2026-08-11 03:51:25 -05:00

(Migrated from github.com)

Meaning #3112? It feels like you can end up with either orientation of code/GOT in RAM/flash so you have that problem either way.

I looked through the relevant libc.a and libm.a for the https://github.com/arm/arm-toolchain/releases/tag/release-22.1.0-ATfE release that Peter mentioned. Disassembled with relocations, I don't see any R_ARM_GOT* relocations. Am I looking in the wrong place?

Meaning #3112? It feels like you can end up with either orientation of code/GOT in RAM/flash so you have that problem either way. I looked through the relevant `libc.a` and `libm.a` for the https://github.com/arm/arm-toolchain/releases/tag/release-22.1.0-ATfE release that Peter mentioned. Disassembled with relocations, I don't see any `R_ARM_GOT*` relocations. Am I looking in the wrong place?

Wren6991 (Migrated from github.com) approved these changes

2026-08-11 04:43:34 -05:00

Wren6991 (Migrated from github.com) left a comment