Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[LoongArch] dead loop after nightly-2024-02-12 #121289

Closed
heiher opened this issue Feb 19, 2024 · 10 comments · Fixed by #121291
Closed

[LoongArch] dead loop after nightly-2024-02-12 #121289

heiher opened this issue Feb 19, 2024 · 10 comments · Fixed by #121291
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. I-hang Issue: The compiler never terminates, due to infinite loops, deadlock, livelock, etc. O-loongarch Target: LoongArch (LA32R, LA32S, LA64) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@heiher
Copy link
Contributor

heiher commented Feb 19, 2024 •
edited
Loading

I tried this code:

rustc -vV
cargo -vV

I expected to see this happen: outputs version info

Instead, this happened: dead loop in main entry function.

Meta

rustc --version --verbose:

a84bb95a1 2024-02-13

b381d3ab2 2024-02-12 good
a84bb95a1 2024-02-13 bad
@heiher heiher added the C-bug Category: This is a bug. label Feb 19, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Feb 19, 2024
@heiher heiher changed the title [Loongarch] dead loop after nightly-2024-02-12 [LoongArch] dead loop after nightly-2024-02-12 Feb 19, 2024
@heiher
Copy link
Contributor Author

heiher commented Feb 19, 2024

@rustbot label O-loongarch

@rustbot rustbot added the O-loongarch Target: LoongArch (LA32R, LA32S, LA64) label Feb 19, 2024
@jieyouxu jieyouxu added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-hang Issue: The compiler never terminates, due to infinite loops, deadlock, livelock, etc. and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Feb 19, 2024
@nikic nikic added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Feb 19, 2024
@nikic
Copy link
Contributor

nikic commented Feb 19, 2024

That would be due to the LLVM 18 upgrade.

@heiher
Copy link
Contributor Author

heiher commented Feb 19, 2024 •
edited
Loading

That would be due to the LLVM 18 upgrade.

Yeah. It seems that the CI loongarch64-unknown-linux-gnu ld does not handle R_LARCH_CALL36 (pcaddu18+jirl) relocations correctly.

0000000000000a40 <main>:                           
   a40:   02ffc063    addi.d          $sp, $sp, -16  
   a44:   29c02061    st.d            $ra, $sp, 8    
   a48:   001500a6    move            $a2, $a1       
   a4c:   02800085    addi.w          $a1, $a0, 0    
   a50:   1a000024    pcalau12i       $a0, 1         
   a54:   02e88084    addi.d          $a0, $a0, -1504
   a58:   03800c07    li.w            $a3, 0x3       
>  a5c:   1e000001    pcaddu18i       $ra, 0         # loop
>  a60:   4c000021    jirl            $ra, $ra, 0    
   a64:   28c02061    ld.d            $ra, $sp, 8    
   a68:   02c04063    addi.d          $sp, $sp, 16   
   a6c:   4c000020    ret

@heiher
Copy link
Contributor Author

heiher commented Feb 19, 2024

There is no version of crosstool-ng that supports R_LARCH_CALL36, I'll revert the medium code model until the issue is resolved.

@heiher heiher mentioned this issue Feb 19, 2024
Merged
@xry111
Copy link
Contributor

xry111 commented Feb 19, 2024

Oooops. Is this communicated with crosstool-ng maintainers?

@xry111
Copy link
Contributor

xry111 commented Feb 19, 2024

But maybe crosstool-ng maintainers can't act as well due to the incompatibility between GCC 13.2 and Binutils 2.42 (loongson-community/discussions#41) :(. I'm not sure how to fix such an incompatibility...

@heiher
Copy link
Contributor Author

heiher commented Feb 19, 2024

Oooops. Is this communicated with crosstool-ng maintainers?

Not yet. binutils 2.42 in progress: crosstool-ng/crosstool-ng#2095

Noratrieb added a commit to Noratrieb/rust that referenced this issue Feb 20, 2024
@Noratrieb
Rollup merge of rust-lang#121291 - heiher:revert-medium-cmodel, r=Nil…
71ed0b9 
…strieb

target: Revert default to the medium code model on LoongArch targets

This reverts commit 35dad14.

Fixes rust-lang#121289
Noratrieb added a commit to Noratrieb/rust that referenced this issue Feb 20, 2024
@Noratrieb
Rollup merge of rust-lang#121291 - heiher:revert-medium-cmodel, r=Nil…
5540d81 
…strieb

target: Revert default to the medium code model on LoongArch targets

This reverts commit 35dad14.

Fixes rust-lang#121289
@bors bors closed this as completed in 9c32a7d Feb 20, 2024
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Feb 20, 2024
@rust-timer
Unrolled build for rust-lang#121291
6db8721 
Rollup merge of rust-lang#121291 - heiher:revert-medium-cmodel, r=Nilstrieb

target: Revert default to the medium code model on LoongArch targets

This reverts commit 35dad14.

Fixes rust-lang#121289
heiher added a commit to heiher/rust that referenced this issue Aug 13, 2024
@heiher
Update crosstool-ng for loongarch64
cebae30 
The current cross-compilation toolchain for the LoongArch64 target
consists of GCC 13.2.0, Binutils 2.40, and Glibc 2.36. However, Binutils
2.40 has known issues that in broken binaries without any error reports:

- rust-lang#121289
- cross-rs/cross#1538

This patch upgrades the cross-compilation toolchain for the LoongArch64 target
to resolve these issues.

- GCC: 13.2.0 -> 14.2.0
- Binutils: 2.40 -> 2.42

The new binaries remain compatible with the existing GCC 13.2.0/Glibc 2.36
distribution, and no issues have been identified.
@heiher heiher mentioned this issue Aug 13, 2024
Merged
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 14, 2024
@bors
Auto merge of rust-lang#129048 - heiher:update-crosstool-loongarch64,…
19d9ce7 
… r=<try>

Update `crosstool-ng` for loongarch64

The current cross-compilation toolchain for the LoongArch64 target consists of GCC 13.2.0, Binutils 2.40, and Glibc 2.36. However, Binutils 2.40 has known issues that in broken binaries without any error reports:

- rust-lang#121289
- cross-rs/cross#1538

This patch upgrades the cross-compilation toolchain for the LoongArch64 target to resolve these issues.

- GCC: 13.2.0 -> 14.2.0
- Binutils: 2.40 -> 2.42

The new binaries remain compatible with the existing GCC 13.2.0/Glibc 2.36 distribution, and no issues have been identified.

try-job: dist-loongarch64-linux
tgross35 added a commit to tgross35/rust that referenced this issue Aug 19, 2024
@tgross35
Rollup merge of rust-lang#129048 - heiher:update-crosstool-loongarch6…
582b0a6 
…4, r=Mark-Simulacrum

Update `crosstool-ng` for loongarch64

The current cross-compilation toolchain for the LoongArch64 target consists of GCC 13.2.0, Binutils 2.40, and Glibc 2.36. However, Binutils 2.40 has known issues that in broken binaries without any error reports:

- rust-lang#121289
- cross-rs/cross#1538

This patch upgrades the cross-compilation toolchain for the LoongArch64 target to resolve these issues.

- GCC: 13.2.0 -> 14.2.0
- Binutils: 2.40 -> 2.42

The new binaries remain compatible with the existing GCC 13.2.0/Glibc 2.36 distribution, and no issues have been identified.

try-job: dist-loongarch64-linux
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Aug 19, 2024
@rust-timer
Unrolled build for rust-lang#129048
f9f3f06 
Rollup merge of rust-lang#129048 - heiher:update-crosstool-loongarch64, r=Mark-Simulacrum

Update `crosstool-ng` for loongarch64

The current cross-compilation toolchain for the LoongArch64 target consists of GCC 13.2.0, Binutils 2.40, and Glibc 2.36. However, Binutils 2.40 has known issues that in broken binaries without any error reports:

- rust-lang#121289
- cross-rs/cross#1538

This patch upgrades the cross-compilation toolchain for the LoongArch64 target to resolve these issues.

- GCC: 13.2.0 -> 14.2.0
- Binutils: 2.40 -> 2.42

The new binaries remain compatible with the existing GCC 13.2.0/Glibc 2.36 distribution, and no issues have been identified.

try-job: dist-loongarch64-linux
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Aug 20, 2024
@tgross35
Rollup merge of #129048 - heiher:update-crosstool-loongarch64, r=Mark…
ed1c0ac 
…-Simulacrum

Update `crosstool-ng` for loongarch64

The current cross-compilation toolchain for the LoongArch64 target consists of GCC 13.2.0, Binutils 2.40, and Glibc 2.36. However, Binutils 2.40 has known issues that in broken binaries without any error reports:

- rust-lang/rust#121289
- cross-rs/cross#1538

This patch upgrades the cross-compilation toolchain for the LoongArch64 target to resolve these issues.

- GCC: 13.2.0 -> 14.2.0
- Binutils: 2.40 -> 2.42

The new binaries remain compatible with the existing GCC 13.2.0/Glibc 2.36 distribution, and no issues have been identified.

try-job: dist-loongarch64-linux
@xen0n
Copy link
Contributor

xen0n commented Sep 6, 2024

#129048 is merged recently that bumped the LoongArch binutils to 2.42, so can we try #120661 again?

@heiher
Copy link
Contributor Author

heiher commented Sep 6, 2024

#129048 is merged recently that bumped the LoongArch binutils to 2.42, so can we try #120661 again?

Yes, with #129048 merged, we can retry #120661.

@heiher heiher mentioned this issue Sep 12, 2024
Merged
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Sep 13, 2024
@matthiaskrgr
Rollup merge of rust-lang#130266 - heiher:loong-medium-cmodel, r=comp…
778f6fb 
…iler-errors

target: default to the medium code model on LoongArch targets

The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219 [1], one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.

Because:

* we do not want to ask users to recompile std if they are to build such software,
* objects compiled with larger code models can be linked with those with smaller code models without problems, and
* the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,

it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.

Relands [2]:  rust-lang#120661

[1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models
[2]: rust-lang#121289 (comment)
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Sep 13, 2024
@rust-timer
Unrolled build for rust-lang#130266
c8ccedf 
Rollup merge of rust-lang#130266 - heiher:loong-medium-cmodel, r=compiler-errors

target: default to the medium code model on LoongArch targets

The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219 [1], one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.

Because:

* we do not want to ask users to recompile std if they are to build such software,
* objects compiled with larger code models can be linked with those with smaller code models without problems, and
* the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,

it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.

Relands [2]:  rust-lang#120661

[1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models
[2]: rust-lang#121289 (comment)
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Sep 14, 2024
@matthiaskrgr
Rollup merge of #130266 - heiher:loong-medium-cmodel, r=compiler-errors
c48577c 
target: default to the medium code model on LoongArch targets

The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As described in the "Code Model" section of LoongArch ELF psABI spec v20231219 [1], one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.

Because:

* we do not want to ask users to recompile std if they are to build such software,
* objects compiled with larger code models can be linked with those with smaller code models without problems, and
* the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,

it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.

Relands [2]:  #120661

[1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models
[2]: rust-lang/rust#121289 (comment)
@xen0n
Copy link
Contributor

xen0n commented Sep 14, 2024

Today's nightly is built off of #130312, which contains #130266 and does work:

$ rustc -Vv
rustc 1.83.0-nightly (0609062a9 2024-09-13)
binary: rustc
commit-hash: 0609062a91c8f445c3e9a0de57e402f9b1b8b0a7
commit-date: 2024-09-13
host: loongarch64-unknown-linux-gnu
release: 1.83.0-nightly
LLVM version: 19.1.0

And the medium code model is indeed in use:

$ readelf -r ~/.rustup/toolchains/nightly-loongarch64-unknown-linux-gnu/lib/rustlib/loongarch64-unknown-linux-gnu/lib/libcore-c292f7f95e655c4c.rlib | grep 'R_LARCH_CALL36' | wc -l
769

So this issue is finally resolved. Thanks for everyone involved!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. I-hang Issue: The compiler never terminates, due to infinite loops, deadlock, livelock, etc. O-loongarch Target: LoongArch (LA32R, LA32S, LA64) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

target: Revert default to the medium code model on LoongArch targets
6 participants
@nikic @xen0n @heiher @xry111 @jieyouxu @rustbot