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.

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

Static variables are not exported on multiple platforms. #99596

Closed
Jake-Shadle opened this issue Jul 22, 2022 · 6 comments
Closed

Static variables are not exported on multiple platforms. #99596

Jake-Shadle opened this issue Jul 22, 2022 · 6 comments
Labels
A-linkage Area: linking into static, shared libraries and binaries C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Jake-Shadle
Copy link

Jake-Shadle commented Jul 22, 2022

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
@Jake-Shadle Jake-Shadle added the C-bug Category: This is a bug. label Jul 22, 2022
@bjorn3
Copy link
Member

bjorn3 commented Jul 22, 2022

Regression range: d68e7eb...62b272d I expect this to be caused by #93718 cc @thomcc

@bjorn3 bjorn3 added A-linkage Area: linking into static, shared libraries and binaries O-wasm Target: WASM (WebAssembly), http://webassembly.org/ labels Jul 22, 2022
@robbert-vdh
Copy link

This also seems to affect at least x86_64-unknown-linux-gnu, x86_64-pc-windows-gnu, x86_64-apple-darwin, and aarch64-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
Copy link
Member

thomcc commented Jul 24, 2022

Hm, interesting. That doesn't make much sense at I suspect this is an issue with how we compile #[used(linker)]? That patch just selects between #[used(linker)] and #[used(compiler)] based on some settings. (No, the original code was badly broken) CC @nikic, who might have more of an idea about why it may be broken.

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)

@thomcc thomcc removed the O-wasm Target: WASM (WebAssembly), http://webassembly.org/ label Jul 24, 2022
@thomcc thomcc changed the title Static variables are not exported when targeting wasm32-unknown-unknown Static variables are not exported on multiple platforms. Jul 24, 2022
@thomcc
Copy link
Member

thomcc commented 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.

@thomcc thomcc added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Jul 24, 2022
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
Don't overwrite CodegenFnAttrs when adding used compiler/linker

Pointed out by `@tmiasko` in rust-lang#93718 (comment). Probably a better fix than rust-lang#99674 for rust-lang#99596, assuming it does fix the latter.

I don't have the ability to write a regression test for this at the moment, and am quite surprised this didn't cause other failures. The old code is clearly wrong though, but I'm not picky as to which of these is better to go with.
@thomcc
Copy link
Member

thomcc commented 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
Copy link
Author

Confirmed, nightly build went green again, I'll mark this issue as fixed.

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. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants