Handle GOT sections gracefully #3064

New issue

Closed

opened 2026-07-07 19:54:16 -05:00 by Prabhuk · 5 comments

Prabhuk commented

2026-07-07 19:54:16 -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 in ARM targets. We observed this in the LLVM runtime libraries (libc.a/libm.a) but this behavior is not specific to Clang/LLVM toolchains. Handle GOT sections gracefully to prevent possible broken behavior.

kilograham commented

2026-07-14 17:27:00 -05:00

(Migrated from github.com)

ok, so what is the upshot - does it fail linking, or what? I'm not keen to include the .got sections in the linker script - we could discard them, or assert they are empty (are they?)

does adding -fno-pic or fno-pie to compile/link help?

ok, so what is the upshot - does it fail linking, or what? I'm not keen to include the `.got` sections in the linker script - we could discard them, or assert they are empty (are they?) does adding `-fno-pic` or `fno-pie` to compile/link help?

Prabhuk commented

2026-07-16 15:08:07 -05:00

(Migrated from github.com)

Having said that, the push back against this patch is fair. We currently build our LLVM libc distributions in PIC mode by default. A recent change upstream https://github.com/llvm/llvm-project/pull/198577 caused GOT sections being introduced in our libm.a which prompted the proposed change. We are working with upstream to resolve this particular case through this patch https://github.com/llvm/llvm-project/pull/209660 which should make our current change here to place GOT sections in linker script irrelevant.

I am still in favor of having the GOT sections handled in one way or the other given it is not illegal for them to be present in the final binary. Assuming we will get the GOT sections removed in our toolchain distribution, the other approach is to actually assert from linker script that no GOT sections exist in the input sections list. I'd prefer that GOT sections are not quietly ignored, if present, causing runtime crashes.

Even if the final link of the binary has no PIC flags set, there might be valid GOT sections coming from libraries that are linked if they were built as PIC. In this scenario, we will not see a compile/link failure but we will end up dropping valid GOT sections leading to runtime failures. Having said that, the push back against this patch is fair. We currently build our LLVM libc distributions in PIC mode by default. A recent change upstream https://github.com/llvm/llvm-project/pull/198577 caused GOT sections being introduced in our libm.a which prompted the proposed change. We are working with upstream to resolve this particular case through this patch https://github.com/llvm/llvm-project/pull/209660 which should make our current change here to place GOT sections in linker script irrelevant. I am still in favor of having the GOT sections handled in one way or the other given it is not illegal for them to be present in the final binary. Assuming we will get the GOT sections removed in our toolchain distribution, the other approach is to actually assert from linker script that no GOT sections exist in the input sections list. I'd prefer that GOT sections are not quietly ignored, if present, causing runtime crashes.

kilograham commented

2026-07-16 16:13:08 -05:00

(Migrated from github.com)

Yup - I was leaning towards an assertion but that doesn’t help obviously if we have toolchain versions that produce them

I wonder even if present if they actually work as intended - can u point me at something that produces them

Yup - I was leaning towards an assertion but that doesn’t help obviously if we have toolchain versions that produce them I wonder even if present if they actually work as intended - can u point me at something that produces them

Prabhuk commented

2026-07-16 16:29:25 -05:00

(Migrated from github.com)

The current version of the clang toolchain in pico-sdk does not produce GOT sections. I can make sure that we dont update the toolchain version to one which emits GOT sections.

"I wonder even if present if they actually work as intended - can u point me at something that produces them" -- In the problematic toolchain revisions used in our ecosystem, accessing this symbol became a GOT relocation: https://github.com/llvm/llvm-project/blob/main/libc/src/__support/FPUtil/rounding_mode.h#L30-L89 from many of our math library functions. This crashed some our products which we fixed by placing the GOT sections in linker scripts. We did not hit this sort of failure in pipico as we have not used a toolchain version which has this issue. My aim here is to proactively handle GOT sections correctly. I can hold off on placing the GOT sections and instead directly emit assertions for pico-sdk.

To answer your question directly, using this revision for clang toolchain will be able to help reproduce the failure mode: b8e34c5adc38b5406d175e7e94c95f6399da096a

I may not have time this week to get through this experiment to produce an example for pico-sdk.

The current version of the clang toolchain in pico-sdk does not produce GOT sections. I can make sure that we dont update the toolchain version to one which emits GOT sections. "I wonder even if present if they actually work as intended - can u point me at something that produces them" -- In the problematic toolchain revisions used in our ecosystem, accessing this symbol became a GOT relocation: https://github.com/llvm/llvm-project/blob/main/libc/src/__support/FPUtil/rounding_mode.h#L30-L89 from many of our math library functions. This crashed some our products which we fixed by placing the GOT sections in linker scripts. We did not hit this sort of failure in pipico as we have not used a toolchain version which has this issue. My aim here is to proactively handle GOT sections correctly. I can hold off on placing the GOT sections and instead directly emit assertions for pico-sdk. To answer your question directly, using this revision for clang toolchain will be able to help reproduce the failure mode: b8e34c5adc38b5406d175e7e94c95f6399da096a I may not have time this week to get through this experiment to produce an example for pico-sdk.

kilograham commented

2026-08-18 09:49:22 -05:00

(Migrated from github.com)