Skip to content

Revert "Fix linking statics on Arm64EC #140176" #141024

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

Merged
merged 1 commit into from
May 17, 2025

Conversation

jieyouxu
Copy link
Member

@jieyouxu jieyouxu commented May 15, 2025

This reverts PR #140176.
Unfortunately, this will reopen #138541 (re-breaking the arm64ec-pc-windows-msvc target).

Unfortunately, multiple people are reporting linker warnings related to __rust_no_alloc_shim_is_unstable after this change in x86_64-pc-windows-msvc as well. The solution isn't quite clear yet, let's revert to avoid the linker warnings on the Tier 1 MSVC target for now1, and try a reland with a determined solution for __rust_no_alloc_shim_is_unstable.

Judging from people reporting that they are observing this also when bootstrapping w/ stage0 rustc, we may have to cut a new beta and then repoint stage0 against that newer beta?

cc @dpaoliello @wesleywiser

r? @wesleywiser (or compiler)

Footnotes

  1. Note that it's still RustWeek this week, so most team members are N/A.

Unfortunately, multiple people are reporting linker warnings related to
`__rust_no_alloc_shim_is_unstable` after this change. The solution isn't
quite clear yet, let's revert to green for now, and try a reland with a
determined solution for `__rust_no_alloc_shim_is_unstable`.

This reverts commit c8b7f32, reversing
changes made to 667247d.
@rustbot rustbot added A-run-make Area: port run-make Makefiles to rmake.rs S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 15, 2025
@rustbot
Copy link
Collaborator

rustbot commented May 15, 2025

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

These commits modify compiler targets.
(See the Target Tier Policy.)

@jieyouxu
Copy link
Member Author

jieyouxu commented May 15, 2025

Nominating this for beta backport because people are reporting seeing the linker warning in bootstrapping as well. However, the beta backport is a "pick your poison" situation, where we avoid the linker warnings in Tier 1 x86_64-pc-windows-msvc target but re-break Tier 2 arm64ec-pc-windows-msvc target.

@rustbot label: +beta-nominated

@rustbot rustbot added the beta-nominated Nominated for backporting to the compiler in the beta channel. label May 15, 2025
Copy link
Member

@wesleywiser wesleywiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r=me when CI is green

@jieyouxu
Copy link
Member Author

CI is green.
@bors r=@wesleywiser rollup=never

@bors
Copy link
Collaborator

bors commented May 15, 2025

📌 Commit 734a5b1 has been approved by wesleywiser

It is now in the queue for this repository.

@bors
Copy link
Collaborator

bors commented May 15, 2025

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 15, 2025
@bors
Copy link
Collaborator

bors commented May 17, 2025

⌛ Testing commit 734a5b1 with merge b0e9259...

@bors
Copy link
Collaborator

bors commented May 17, 2025

☀️ Test successful - checks-actions
Approved by: wesleywiser
Pushing b0e9259 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label May 17, 2025
@bors bors merged commit b0e9259 into rust-lang:master May 17, 2025
7 checks passed
@rustbot rustbot added this to the 1.89.0 milestone May 17, 2025
Copy link
Contributor

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing a69bc17 (parent) -> b0e9259 (this PR)

Test differences

Show 3 test diffs

Stage 1

  • [run-make] tests/run-make/arm64ec-import-export-static: ignore (only executed when the operating system is windows) -> [missing] (J2)

Stage 2

  • [run-make] tests/run-make/arm64ec-import-export-static: ignore (only executed when the operating system is windows) -> [missing] (J0)
  • [run-make] tests/run-make/arm64ec-import-export-static: pass -> [missing] (J1)

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard b0e925903a04fc3b2e0903ce6110938e871c61a1 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. x86_64-apple-2: 5192.9s -> 6222.2s (19.8%)
  2. dist-apple-various: 7238.6s -> 6165.7s (-14.8%)
  3. x86_64-rust-for-linux: 2561.4s -> 2824.7s (10.3%)
  4. dist-x86_64-illumos: 5648.2s -> 6162.8s (9.1%)
  5. mingw-check: 1216.0s -> 1314.9s (8.1%)
  6. dist-x86_64-apple: 8418.5s -> 8995.4s (6.9%)
  7. dist-i686-msvc: 7067.4s -> 6718.1s (-4.9%)
  8. dist-various-1: 4403.6s -> 4620.9s (4.9%)
  9. dist-arm-linux: 4578.8s -> 4797.6s (4.8%)
  10. aarch64-gnu: 6647.8s -> 6337.5s (-4.7%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (b0e9259): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -1.6%, secondary -2.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.2% [2.2%, 2.2%] 1
Regressions ❌
(secondary)
0.7% [0.5%, 1.1%] 6
Improvements ✅
(primary)
-2.3% [-4.2%, -0.8%] 6
Improvements ✅
(secondary)
-2.5% [-3.7%, -1.0%] 36
All ❌✅ (primary) -1.6% [-4.2%, 2.2%] 7

Cycles

Results (secondary -0.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
1.3% [0.6%, 2.1%] 2
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.6% [-0.7%, -0.4%] 5
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 774.345s -> 775.66s (0.17%)
Artifact size: 365.45 MiB -> 365.38 MiB (-0.02%)

@apiraino
Copy link
Contributor

Beta backport accepted as per compiler team on Zulip and here. A backport PR will be authored by the release team at the end of the current development cycle. Backport labels handled by them.

@rustbot label +beta-accepted

@rustbot rustbot added the beta-accepted Accepted for backporting to the compiler in the beta channel. label May 22, 2025
@cuviper cuviper modified the milestones: 1.89.0, 1.88.0 May 22, 2025
@cuviper cuviper removed the beta-nominated Nominated for backporting to the compiler in the beta channel. label May 22, 2025
bors added a commit to rust-lang-ci/rust that referenced this pull request May 23, 2025
[beta] backports and stage0 bump

- bump stage0
- Update the edition guide for let chains rust-lang#140852
- Fix download of GCC from CI on non-nightly channels rust-lang#140901
- Revert "Fix linking statics on Arm64EC rust-lang#140176" rust-lang#141024
- [win][arm64] Remove 'Arm64 Hazard' undocumented MSVC option and instead disable problematic test rust-lang#141045
- Do not call name() on rpitit assoc_item rust-lang#141308

r? cuviper
bors added a commit that referenced this pull request May 23, 2025
[beta] backports and stage0 bump

- bump stage0 to 1.87.0
- Update the edition guide for let chains #140852
- Fix download of GCC from CI on non-nightly channels #140901
- Revert "Fix linking statics on Arm64EC #140176" #141024
- [win][arm64] Remove 'Arm64 Hazard' undocumented MSVC option and instead disable problematic test #141045
- Do not call name() on rpitit assoc_item #141308
- Temporarily use Windows Server 2022 instead of Windows Server 2025 images #141023

r? cuviper
bors added a commit that referenced this pull request May 24, 2025
[beta] backports and stage0 bump

- bump stage0 to 1.87.0
- Update the edition guide for let chains #140852
- Fix download of GCC from CI on non-nightly channels #140901
- Revert "Fix linking statics on Arm64EC #140176" #141024
- [win][arm64] Remove 'Arm64 Hazard' undocumented MSVC option and instead disable problematic test #141045
- Do not call name() on rpitit assoc_item #141308
- Temporarily use Windows Server 2022 instead of Windows Server 2025 images #141023
- Use Docker cache from the current repository #141280
- Move dist-x86_64-linux CI job to GitHub temporarily #141388
- ci: prepare aws access keys for migration #141389

r? cuviper
bors added a commit that referenced this pull request May 25, 2025
[beta] backports and stage0 bump

- bump stage0 to 1.87.0
- Update the edition guide for let chains #140852
- Fix download of GCC from CI on non-nightly channels #140901
- Revert "Fix linking statics on Arm64EC #140176" #141024
- [win][arm64] Remove 'Arm64 Hazard' undocumented MSVC option and instead disable problematic test #141045
- Do not call name() on rpitit assoc_item #141308
- Temporarily use Windows Server 2022 instead of Windows Server 2025 images #141023
- Use Docker cache from the current repository #141280
- Move dist-x86_64-linux CI job to GitHub temporarily #141388
- ci: prepare aws access keys for migration #141389
- Add bors environment to CI #141323

r? cuviper
bors added a commit that referenced this pull request May 25, 2025
[beta] backports and stage0 bump

- bump stage0 to 1.87.0
- Update the edition guide for let chains #140852
- Fix download of GCC from CI on non-nightly channels #140901
- Revert "Fix linking statics on Arm64EC #140176" #141024
- [win][arm64] Remove 'Arm64 Hazard' undocumented MSVC option and instead disable problematic test #141045
- Do not call name() on rpitit assoc_item #141308
- Temporarily use Windows Server 2022 instead of Windows Server 2025 images #141023
- Use Docker cache from the current repository #141280
- Move dist-x86_64-linux CI job to GitHub temporarily #141388
- ci: prepare aws access keys for migration #141389
- Add bors environment to CI #141323
-  ci: split dist-arm-linux job #141078

r? cuviper
jieyouxu added a commit to jieyouxu/rust that referenced this pull request May 27, 2025
To include beta backport of revert rust-lang#141024 which should undo linker
warnings during bootstrapping of Windows MSVC targets due to rust-lang#140176.
jieyouxu added a commit to jieyouxu/rust that referenced this pull request May 27, 2025
To include beta backport of revert
<rust-lang#141024> which should undo linker
warnings during bootstrapping of Windows MSVC targets due to
<rust-lang#140176>.
tgross35 added a commit to tgross35/rust that referenced this pull request May 28, 2025
…troalbini

Bump master `stage0` compiler

To include beta backport of revert rust-lang#141024 which should undo linker warnings during bootstrapping of Windows MSVC targets due to rust-lang#140176.

Closes rust-lang#141395.

r? `@Mark-Simulacrum` (or release)
rust-timer added a commit that referenced this pull request May 28, 2025
Rollup merge of #141647 - jieyouxu:bump-master-stage0, r=pietroalbini

Bump master `stage0` compiler

To include beta backport of revert #141024 which should undo linker warnings during bootstrapping of Windows MSVC targets due to #140176.

Closes #141395.

r? `@Mark-Simulacrum` (or release)
github-actions bot pushed a commit to rust-lang/miri that referenced this pull request May 28, 2025
Bump master `stage0` compiler

To include beta backport of revert rust-lang/rust#141024 which should undo linker warnings during bootstrapping of Windows MSVC targets due to rust-lang/rust#140176.

Closes rust-lang/rust#141395.

r? `@Mark-Simulacrum` (or release)
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Jun 7, 2025
Change __rust_no_alloc_shim_is_unstable to be a function

This fixes a long sequence of issues:

1. A customer reported that building for Arm64EC was broken: rust-lang#138541
2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well.
3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data.
4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not).
5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning.
6. A customer then reported a similar warning when using `lld-link` (<rust-lang#140176 (comment)>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: rust-lang#140954.
7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <rust-lang#140176 (comment)>. At that point, my original change was reverted (rust-lang#141024) leaving Arm64EC broken yet again.

Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported.

Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not.

There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above.

There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics).

Build with this change applied BEFORE rust-lang#140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205>

Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for rust-lang#128602)

r? `@bjorn3`
cc `@jieyouxu`
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Jun 10, 2025
Change __rust_no_alloc_shim_is_unstable to be a function

This fixes a long sequence of issues:

1. A customer reported that building for Arm64EC was broken: rust-lang#138541
2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well.
3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data.
4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not).
5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning.
6. A customer then reported a similar warning when using `lld-link` (<rust-lang#140176 (comment)>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: rust-lang#140954.
7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <rust-lang#140176 (comment)>. At that point, my original change was reverted (rust-lang#141024) leaving Arm64EC broken yet again.

Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported.

Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not.

There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above.

There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics).

Build with this change applied BEFORE rust-lang#140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205>

Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for rust-lang#128602)

r? `@bjorn3`
cc `@jieyouxu`
workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Jun 10, 2025
Change __rust_no_alloc_shim_is_unstable to be a function

This fixes a long sequence of issues:

1. A customer reported that building for Arm64EC was broken: rust-lang#138541
2. This was caused by a bug in my original implementation of Arm64EC support, namely that only functions on Arm64EC need to be decorated with `#` but Rust was decorating statics as well.
3. Once I corrected Rust to only decorate functions, I started linking failures where the linker couldn't find statics exported by dylib dependencies. This was caused by the compiler not marking exported statics in the generated DEF file with `DATA`, thus they were being exported as functions not data.
4. Once I corrected the way that the DEF files were being emitted, the linker started failing saying that it couldn't find `__rust_no_alloc_shim_is_unstable`. This is because the MSVC linker requires the declarations of statics imported from other dylibs to be marked with `dllimport` (whereas it will happily link to functions imported from other dylibs whether they are marked `dllimport` or not).
5. I then made a change to ensure that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport`, but the MSVC linker started emitting warnings that `__rust_no_alloc_shim_is_unstable` was marked as `dllimport` but was declared in an obj file. This is a harmless warning which is a performance hint: anything that's marked `dllimport` must be indirected via an `__imp` symbol so I added a linker arg in the target to suppress the warning.
6. A customer then reported a similar warning when using `lld-link` (<rust-lang#140176 (comment)>). I don't think it was an implementation difference between the two linkers but rather that, depending on the obj that the declaration versus uses of `__rust_no_alloc_shim_is_unstable` landed in we would get different warnings, so I suppressed that warning as well: rust-lang#140954.
7. Another customer reported that they weren't using the Rust compiler to invoke the linker, thus these warnings were breaking their build: <rust-lang#140176 (comment)>. At that point, my original change was reverted (rust-lang#141024) leaving Arm64EC broken yet again.

Taking a step back, a lot of these linker issues arise from the fact that `__rust_no_alloc_shim_is_unstable` is marked as `extern "Rust"` in the standard library and, therefore, assumed to be a foreign item from a different crate BUT the Rust compiler may choose to generate it either in the current crate, some other crate that will be statically linked in OR some other crate that will by dynamically imported.

Worse yet, it is impossible while building a given crate to know if `__rust_no_alloc_shim_is_unstable` will statically linked or dynamically imported: it might be that one of its dependent crates is the one with an allocator kind set and thus that crate (which is compiled later) will decide depending if it has any dylib dependencies or not to import `__rust_no_alloc_shim_is_unstable` or generate it. Thus, there is no way to know if the declaration of `__rust_no_alloc_shim_is_unstable` should be marked with `dllimport` or not.

There is a simple fix for all this: there is no reason `__rust_no_alloc_shim_is_unstable` must be a static. It needs to be some symbol that must be linked in; thus, it could easily be a function instead. As a function, there is no need to mark it as `dllimport` when dynamically imported which avoids the entire mess above.

There may be a perf hit for changing the `volatile load` to be a `tail call`, so I'm happy to change that part back (although I question what the codegen of a `volatile load` would look like, and if the backend is going to try to use load-acquire semantics).

Build with this change applied BEFORE rust-lang#140176 was reverted to demonstrate that there are no linking issues with either MSVC or MinGW: <https://github.com/rust-lang/rust/actions/runs/15078657205>

Incidentally, I fixed `tests/run-make/no-alloc-shim` to work with MSVC as I needed it to be able to test locally (FYI for rust-lang#128602)

r? ``@bjorn3``
cc ``@jieyouxu``
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-run-make Area: port run-make Makefiles to rmake.rs beta-accepted Accepted for backporting to the compiler in the beta channel. merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants