miri: make sure we can find link_section statics even for the local crate

[RalfJung]

Miri needs some way to iterate all the exported functions and "used" statics of all crates. For dependency crates, this already works fine since we can overwrite the query resonsible for computing exported_symbols, but it turns out for local binary crates this does not work: for binaries, reachable_set skips a lot of its logic and only checks contains_extern_indicator() and RUSTC_STD_INTERNAL_SYMBOL. Other flags like CodegenFnAttrFlags::USED are entirely ignored.

This PR proposes to use the same check, has_custom_linkage, in binaries that we already use to drive the main workqueue of the reachability recursive traversal. I have no idea why binaries used a slightly different check that ignores USED -- was that deliberate or does it just not matter most of the time?

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
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]

The Miri subtree was changed

cc @rust-lang/miri

[BoxyUwU]

r? compiler

what's a linker

[RalfJung]

@compiler-errors can I take this as an r=you? I am a bit confused why you didn't r+ if you approved the PR.^^

[compiler-errors]

because i forgot lol

@bors r+

[bors]

📌 Commit d9a3423 has been approved by compiler-errors

It is now in the queue for this repository.

[bors]

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

[ehuss]

@RalfJung This seems to have caused a regression on Windows (at least the -msvc variant).

#[used]
static FOO: u32 = 0;
fn main() {}

This now generates a linking error:

  = note: symbols.o : error LNK2001: unresolved external symbol _ZN1a3FOO17haec9c1cdc2806380E
          C:\Temp\z20\a\target\debug\deps\a-f995ecc6e2b1e691.exe : fatal error LNK1120: 1 unresolved externals

[RalfJung]

I don't know much about what happens during linking... Seems like FOO is somehow missing despite the "used" attribute saying that it should be present? Cc @bjorn3 @ChrisDenton

[ChrisDenton]

Looks weird.

EDIT: That symbol does seem to be in foo.foo.b0bca38e44b57c9a-cgu.0.rcgu.o in my build but the link still fails.

[ChrisDenton]

Oh, now that I've sat down to look at it properly the difference is obvious. We're adding #[used] items to symbols.o, thereby forcing them to be included in the final binary.

Before we only exported symbols from the binary if #[no_mangle] or #[export_name="..."] was used.

[ehuss]

I opened #127052 to track this.