-
Notifications
You must be signed in to change notification settings - Fork 13.4k
failure to link due to unknown relocation type in switch tables (aarch64-linux-*) #141737
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
A-linkage
Area: linking into static, shared libraries and binaries
C-bug
Category: This is a bug.
llvm-fixed-upstream
Issue expected to be fixed by the next major LLVM upgrade, or backported fixes
O-AArch64
Armv8-A or later processors in AArch64 mode
O-linux
Operating system: Linux
P-high
High priority
regression-untriaged
Untriaged performance or correctness regression.
S-has-mcve
Status: A Minimal Complete and Verifiable Example has been found for this issue
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
dianqk
added a commit
to llvm/llvm-project
that referenced
this issue
Jun 1, 2025
…REL relocations (#142304) Follow #72584 (comment), the patch will drop the `unnamed_addr` attribute when generating relative lookup tables. I'm not very confident about this patch, but it does resolve rust-lang/rust#140686, rust-lang/rust#141306 and rust-lang/rust#141737. But I don't think this will result in worse problems. > LLVM provides that the calculation of such a constant initializer will not overflow at link time under the medium code model if x is an unnamed_addr function. However, it does not provide this guarantee for a constant initializer folded into a function body. This intrinsic can be used to avoid the possibility of overflows when loading from such a constant. ([‘llvm.load.relative’ Intrinsic](https://llvm.org/docs/LangRef.html#id2592)) This is my concern. I'm not sure how unnamed_addr provides this guarantee, and I haven't found any test cases.
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this issue
Jun 1, 2025
…ating GOTPCREL relocations (#142304) Follow llvm/llvm-project#72584 (comment), the patch will drop the `unnamed_addr` attribute when generating relative lookup tables. I'm not very confident about this patch, but it does resolve rust-lang/rust#140686, rust-lang/rust#141306 and rust-lang/rust#141737. But I don't think this will result in worse problems. > LLVM provides that the calculation of such a constant initializer will not overflow at link time under the medium code model if x is an unnamed_addr function. However, it does not provide this guarantee for a constant initializer folded into a function body. This intrinsic can be used to avoid the possibility of overflows when loading from such a constant. ([‘llvm.load.relative’ Intrinsic](https://llvm.org/docs/LangRef.html#id2592)) This is my concern. I'm not sure how unnamed_addr provides this guarantee, and I haven't found any test cases.
dianqk
added a commit
to dianqk/llvm-project
that referenced
this issue
Jun 1, 2025
…REL relocations (llvm#142304) Follow llvm#72584 (comment), the patch will drop the `unnamed_addr` attribute when generating relative lookup tables. I'm not very confident about this patch, but it does resolve rust-lang/rust#140686, rust-lang/rust#141306 and rust-lang/rust#141737. But I don't think this will result in worse problems. > LLVM provides that the calculation of such a constant initializer will not overflow at link time under the medium code model if x is an unnamed_addr function. However, it does not provide this guarantee for a constant initializer folded into a function body. This intrinsic can be used to avoid the possibility of overflows when loading from such a constant. ([‘llvm.load.relative’ Intrinsic](https://llvm.org/docs/LangRef.html#id2592)) This is my concern. I'm not sure how unnamed_addr provides this guarantee, and I haven't found any test cases. (cherry picked from commit aa09dbb)
tstellar
pushed a commit
to dianqk/llvm-project
that referenced
this issue
Jun 3, 2025
…REL relocations (llvm#142304) Follow llvm#72584 (comment), the patch will drop the `unnamed_addr` attribute when generating relative lookup tables. I'm not very confident about this patch, but it does resolve rust-lang/rust#140686, rust-lang/rust#141306 and rust-lang/rust#141737. But I don't think this will result in worse problems. > LLVM provides that the calculation of such a constant initializer will not overflow at link time under the medium code model if x is an unnamed_addr function. However, it does not provide this guarantee for a constant initializer folded into a function body. This intrinsic can be used to avoid the possibility of overflows when loading from such a constant. ([‘llvm.load.relative’ Intrinsic](https://llvm.org/docs/LangRef.html#id2592)) This is my concern. I'm not sure how unnamed_addr provides this guarantee, and I haven't found any test cases. (cherry picked from commit aa09dbb)
llvm-sync bot
pushed a commit
to arm/arm-toolchain
that referenced
this issue
Jun 3, 2025
…ating GOTPCREL relocations (#142304) Follow llvm/llvm-project#72584 (comment), the patch will drop the `unnamed_addr` attribute when generating relative lookup tables. I'm not very confident about this patch, but it does resolve rust-lang/rust#140686, rust-lang/rust#141306 and rust-lang/rust#141737. But I don't think this will result in worse problems. > LLVM provides that the calculation of such a constant initializer will not overflow at link time under the medium code model if x is an unnamed_addr function. However, it does not provide this guarantee for a constant initializer folded into a function body. This intrinsic can be used to avoid the possibility of overflows when loading from such a constant. ([‘llvm.load.relative’ Intrinsic](https://llvm.org/docs/LangRef.html#id2592)) This is my concern. I'm not sure how unnamed_addr provides this guarantee, and I haven't found any test cases. (cherry picked from commit aa09dbb)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-linkage
Area: linking into static, shared libraries and binaries
C-bug
Category: This is a bug.
llvm-fixed-upstream
Issue expected to be fixed by the next major LLVM upgrade, or backported fixes
O-AArch64
Armv8-A or later processors in AArch64 mode
O-linux
Operating system: Linux
P-high
High priority
regression-untriaged
Untriaged performance or correctness regression.
S-has-mcve
Status: A Minimal Complete and Verifiable Example has been found for this issue
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Uh oh!
There was an error while loading. Please reload this page.
Split from #141306
MCVE by @dianqk: https://rust.godbolt.org/z/vd4nTc3oj
Fails to link on aarch64-linux-*
Per @briansmith:
aarch64-unknown-linux-gnu
mk/cargo.sh +stable test -vv --target=aarch64-unknown-linux-gnu --release fails to link a test:
aarch64-linux-android
https://github.com/briansmith/ring/actions/runs/15145194221/job/42579103909
mk/cargo.sh +stable test -vv --target=aarch64-linux-android --no-run --release
fails to link a test:@rustbot label: +S-has-mcve +T-compiler +P-high +A-linkage +regression-untriaged
The text was updated successfully, but these errors were encountered: