Fix linking statics on Arm64EC

[dpaoliello]

Arm64EC builds recently started to fail due to the linker not finding a symbol:

symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
          C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals

It turns out that EMPTY_PANIC is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with # (as only functions are prefixed with this character), whereas Rust was prefixing with # when attempting to import it.

The fix is to have Rust not prefix statics with # when importing.

Adding tests discovered another issue: we need to correctly mark static exported from dylibs with DATA, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.

CI found another bug: we only apply DllImport to non-local statics that aren't foreign items (i.e., in an extern block), that is we want to use DllImport for statics coming from other Rust crates. However, __rust_no_alloc_shim_is_unstable is a static generated by the Rust compiler if required, but downstream crates consider it a foreign item since it is declared in an extern "Rust" block, thus they do not apply DllImport to it and so fails to link if it is exported by the previous crate as DATA. The fix is to apply DllImport to foreign items that are marked with the rustc_std_internal_symbol attribute (i.e., we assume they aren't actually foreign and will be in some Rust crate).

Fixes #138541

---

try-job: dist-aarch64-msvc
try-job: dist-x86_64-msvc
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2

[rustbot]

r? @Nadrieril

rustbot has assigned @Nadrieril.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

[wesleywiser]

Changes look good to me. Is it possible to write a regression test? (Either a full-scale integration test that links an exported static from one crate to another or a test that imports a static and dumps the symbol name or something?)

[Nadrieril]

r? @wesleywiser

[wesleywiser]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

This PR modifies run-make tests.

cc @jieyouxu

[dpaoliello]

Changes look good to me. Is it possible to write a regression test? (Either a full-scale integration test that links an exported static from one crate to another or a test that imports a static and dumps the symbol name or something?)

Good call, found another bug: we need to correctly export variables as DATA otherwise the linker expects them to have thunks.

@rustbot ready

[wesleywiser]

Thanks @dpaoliello!

@bors r+ rollup

Also nominating for potential beta backport as this fixes a serious issue for the Tier 2 aarch64-pc-windows-msvc.

[bors]

📌 Commit 7370c5c has been approved by wesleywiser

It is now in the queue for this repository.

[bors]

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

[github-actions]

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 667247d (parent) -> c8b7f32 (this PR)

Test differences

Show 3 test diffs

Stage 1

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

Stage 2

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

Job group index

• J0: aarch64-apple, aarch64-gnu, aarch64-gnu-debug, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, dist-various-1, i686-gnu-1, i686-gnu-nopt-1, test-various, x86_64-apple-1, x86_64-gnu, x86_64-gnu-debug, x86_64-gnu-llvm-19-1, x86_64-gnu-llvm-19-2, x86_64-gnu-llvm-20-1, x86_64-gnu-llvm-20-2, x86_64-gnu-nopt, x86_64-gnu-stable
• J1: i686-msvc-1, x86_64-mingw-1, x86_64-msvc-1
• J2: x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-3

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard c8b7f32434c0306db5c1b974ee43443746098a92 --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: 5691.9s -> 7352.0s (29.2%)
2. dist-aarch64-apple: 4681.1s -> 5540.7s (18.4%)
3. dist-apple-various: 7341.5s -> 8598.3s (17.1%)
4. dist-x86_64-apple: 8512.9s -> 9239.2s (8.5%)
5. x86_64-gnu-llvm-19-1: 5602.0s -> 5282.1s (-5.7%)
6. dist-loongarch64-linux: 6275.5s -> 6603.6s (5.2%)
7. x86_64-apple-1: 7275.7s -> 7608.8s (4.6%)
8. dist-x86_64-netbsd: 4966.2s -> 5169.5s (4.1%)
9. mingw-check: 1249.4s -> 1298.6s (3.9%)
10. dist-i686-mingw: 7957.4s -> 7664.6s (-3.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]

Finished benchmarking commit (c8b7f32): 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 0.1%, secondary 0.2%)

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)	1.6%	[0.4%, 6.5%]	8
Regressions ❌ (secondary)	5.4%	[5.4%, 5.4%]	1
Improvements ✅ (primary)	-1.5%	[-5.0%, -0.5%]	8
Improvements ✅ (secondary)	-1.5%	[-1.9%, -1.1%]	3
All ❌✅ (primary)	0.1%	[-5.0%, 6.5%]	16

Cycles

Results (primary 0.1%, secondary -2.8%)

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.6%	[0.6%, 0.6%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-2.8%	[-2.8%, -2.8%]	1
All ❌✅ (primary)	0.1%	[-0.4%, 0.6%]	2

Binary size

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

Bootstrap: 771.655s -> 771.811s (0.02%)
Artifact size: 365.39 MiB -> 365.31 MiB (-0.02%)

[zmodem]

We're hitting lld errors when building cargo after this change:

locally defined symbol imported: __rust_no_alloc_shim_is_unstable [...] LNK4217

It sounds like something is applying dllimport to __rust_no_alloc_shim_is_unstable even though it's part of the same image.

Actually, I see you're hitting the same thing in this test: https://github.com/rust-lang/rust/pull/140176/files#diff-f31e13197ab771a198513dbb749c33ae9195b4814c5a358deca1294a112adbc1

Is this intentional? And if so, do the build files need to be updated to ignore the warning?

(Our reference: https://crbug.com/417168093)

[dpaoliello]

We're hitting lld errors when building cargo after this change:

locally defined symbol imported: __rust_no_alloc_shim_is_unstable [...] LNK4217

It sounds like something is applying dllimport to __rust_no_alloc_shim_is_unstable even though it's part of the same image.

Actually, I see you're hitting the same thing in this test: https://github.com/rust-lang/rust/pull/140176/files#diff-f31e13197ab771a198513dbb749c33ae9195b4814c5a358deca1294a112adbc1

Is this intentional? And if so, do the build files need to be updated to ignore the warning?

(Our reference: https://crbug.com/417168093)

Yes, this warning is expected: __rust_no_alloc_shim_is_unstable is marked as extern "Rust" in the standard library, but the compiler generates a definition for it.

The correct fix would be for compiler/rustc_codegen_llvm/src/consts.rs to know if the current crate is generating the definition or not (thus whether dllimport is correct or not).

It's interesting that MSVC's linker reported this as warning 4286 whereas lld is reporting it as 4217.

I'll submit a change to ignore 4217 as well.

[zmodem]

Hmm, while that fixes our build of cargo, we're now hitting the same warning when linking Chromium, and we definitely don't want to disable this warning globally.

This seems like a regression.

[dpaoliello]

@bjorn3 is this something you can help with?

There are two ways that this could be fixed without needing a warning suppression for the linker:

• Either consts.rs needs to be made aware of when the compiler is planning to emit the definition for __rust_no_alloc_shim_is_unstable and so it should not be marked as dllimport
• If the compiler is planning to emit the definition of __rust_no_alloc_shim_is_unstable it modifies the corresponding def to mark the static as being local (this needs to be done early enough that const.rs hasn't been called yet).

I don't know enough about the architecture of the compiler to know which of these approaches is plausible, though I would argue that the second is more "correct" (i.e., we are no longer lying to the compiler and telling it that __rust_no_alloc_shim_is_unstable is non-local and foreign, then emitting a definition for it).

[nico]

If it takes a while to figure out a good way forward, would it be possible to revert to green in the meantime?

[erickt]

We're also running into this issue on Fuchsia trying to build our stage0 windows rustc. If we do a revert, could we also cut a new stage0 as well?

[jieyouxu]

The beta backport nomination was rejected in the compiler async backport thread.

@rustbot label: -beta-nominated

[jieyouxu]

The timing here is a bit unfortunate because most team members are N/A this week due to RustWeek / All Hands. I think it's safer to attempt a revert at this time, before we figure out a better solution for __rust_no_alloc_shim_is_unstable.

EDIT: revert PR is #141024.