Repository navigation
Closed
Labels
A-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
It appears that #88092 has regressed in nightly, The last working nightly we used was rustc 1.64.0-nightly (d68e7ebc3 2022-07-20), rustc 1.64.0-nightly (62b272d25 2022-07-21) was the first nightly that stopped working correctly.
I tried this code:
// lib.rs
#[no_mangle]
#[used]
pub static FOO: u64 = 4242;I expected to see this happen:
cargo build --release --target wasm32-unknown-unknown && wasm2wat target/wasm32-unknown-unknown/release/missing_symbols.wasm
In rustc 1.62.0 (a8314ef7d 2022-06-27), this properly exports the FOO static.
(module
(table (;0;) 1 1 funcref)
(memory (;0;) 17)
(global $__stack_pointer (mut i32) (i32.const 1048576))
(global (;1;) i32 (i32.const 1048576))
(global (;2;) i32 (i32.const 1048584))
(global (;3;) i32 (i32.const 1048592))
(export "memory" (memory 0))
(export "FOO" (global 1))
(export "__data_end" (global 2))
(export "__heap_base" (global 3))
(data $.rodata (i32.const 1048576) "\92\10\00\00\00\00\00\00"))Instead, this happened:
cargo +nightly build --release --target wasm32-unknown-unknown && wasm2wat target/wasm32-unknown-unknown/release/missing_symbols.wasm
In rustc 1.64.0-nightly (62b272d25 2022-07-21), FOO is not exported.
(module
(table (;0;) 1 1 funcref)
(memory (;0;) 16)
(global $__stack_pointer (mut i32) (i32.const 1048576))
(global (;1;) i32 (i32.const 1048576))
(global (;2;) i32 (i32.const 1048576))
(export "memory" (memory 0))
(export "__data_end" (global 1))
(export "__heap_base" (global 2)))Meta
rustc --version --verbose:
rustc 1.64.0-nightly (62b272d25 2022-07-21)
binary: rustc
commit-hash: 62b272d25c5bb8b6bb8ac73797d82b8b9a1eabda
commit-date: 2022-07-21
host: x86_64-unknown-linux-gnu
release: 1.64.0-nightly
LLVM version: 14.0.6
Reacted by repi
Metadata
Metadata
Assignees
Labels
A-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.Category: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
bjorn3 commentedon Jul 22, 2022
Regression range: d68e7eb...62b272d I expect this to be caused by #93718 cc @thomcc
robbert-vdh commentedon Jul 24, 2022
This also seems to affect at least
x86_64-unknown-linux-gnu,x86_64-pc-windows-gnu,x86_64-apple-darwin, andaarch64-apple-darwin. Since about three days ago#[no_mangle]+#[used]static symbols no longer appear in the data section (/other platform's equivalents). With an explicit#[used(linker)]it works, but that feature is of course still unstable.thomcc commentedon Jul 24, 2022
Hm, interesting.
That doesn't make much sense at I suspect this is an issue with how we compile(No, the original code was badly broken) CC @nikic, who might have more of an idea about why it may be broken.#[used(linker)]? That patch just selects between#[used(linker)]and#[used(compiler)]based on some settings.I don't have time to fix this right now, and it's very non-obvious to me why this would happen, so if it's as broken as @robbert-vdh suggests, the PR should probably be reverted.
(Removing O-wasm based on the previous comment)
[-]Static variables are not exported when targeting `wasm32-unknown-unknown`[/-][+]Static variables are not exported on multiple platforms.[/+]thomcc commentedon Jul 24, 2022
The first PR should definitely fix this. The second fixes the bug. I don't really have the ability to dig into this at the moment, but this should unblock either option.
That said, some evidence in favor of reverting is that this may have been fixed between when I wrote that PR and when it landed (which was quite a long time), perhaps by #95604 ? Not sure.
Auto merge of rust-lang#99676 - thomcc:dont-overwrite, r=tmiasko
thomcc commentedon Jul 26, 2022
@Jake-Shadle @robbert-vdh Can you confirm that this is fixed in
rustc 1.64.0-nightly (6dbae3ad1 2022-07-25)? (Or later)Jake-Shadle commentedon Jul 26, 2022
Confirmed, nightly build went green again, I'll mark this issue as fixed.