MSVC: Avoid using jmp stubs for dll function imports

[ChrisDenton]

Windows import libraries contain two symbols for every function: __imp_FunctionName and FunctionName (where FunctionName is the name of the function to be imported).

__imp_FunctionName contains the address of the imported function. This will be filled in by the Windows executable loader at runtime. FunctionName contains a jmp stub that simply jumps to the address given by __imp_FunctionName. E.g. it's a function that solely contains a single jmp instruction:

jmp __imp_FunctionName

When using an external DLL function in Rust, by default the linker will link to FunctionName, causing a bit of indirection at runtime. In Microsoft's C++ it's possible to instead tell it to insert calls to the address in __imp_FunctionName by using the __declspec(dllimport) attribute. In Rust it's possible to get effectively the same behaviour using the #[link] attribute on extern blocks.

---

The second commit also merges multiple extern blocks into one block. This is because otherwise Rust will currently create duplicate linker arguments for each block. In this case having duplicates shouldn't matter much other than the noise when displaying the linker command.

[rust-highfive]

r? @dtolnay

(rust-highfive has picked a reviewer for you, use r? to override)

[dtolnay]

Second commit looks good to me -- thank you.

Could I get a sanity check from some Windows pros on the reasoning in #84758 (comment) and the content of f66c678353407015a8f795f2683f7688759b2b72?

@rustbot ping windows

[rustbot]

Hey Windows Group! This bug has been identified as a good "Windows candidate".
In case it's useful, here are some instructions for tackling these sorts of
bugs. Maybe take a look?
Thanks! <3

cc @arlosi @danielframpton @gdr-at-ms @kennykerr @luqmana @lzybkr @nico-abram @retep998 @rylev @sivadeilra @wesleywiser

[nico-abram]

The extern block includes BCryptGenRandom, which according to msdn is in Bcrypt.dll, not kernel32 (Like the link attribute says). Is that correct?

https://github.com/rust-lang/rust/blob/d35d94355d967a076aae85810f43f99b613127b0/library/std/src/sys/windows/c.rs#L716-L717

[ChrisDenton]

The extern block includes BCryptGenRandom, which according to msdn is in Bcrypt.dll, not kernel32 (Like the link attribute says). Is that correct?

This is true. However, Rust's #[link] attribute doesn't currently affect how functions in the associated extern block are found. I'm just using it for the side-effect of triggering the dllimport heuristic.

That said, it might be worth separating them properly for the sake of documentation and future proofing.

[sivadeilra]

The extern block includes BCryptGenRandom, which according to msdn is in Bcrypt.dll, not kernel32 (Like the link attribute says). Is that correct?

This is true. However, Rust's #[link] attribute doesn't currently affect how functions in the associated extern block are found. I'm just using it for the side-effect of triggering the dllimport heuristic.

That said, it might be worth separating them properly for the sake of documentation and future proofing.

It would help to avoid confusion here, by using the correct DLL name. My team is working on implementing the raw-dylib support for Windows, so that the #[link] attribute's specification of the DLL name will be used to generate import tables.

[ChrisDenton]

Ok, I've changed the second commit to use the proper import libraries. Note that #84794 somewhat mitigates the previous issue with duplicate import names, so long as the duplicate #[link] attributes are on consecutive extern blocks. I've taken advantage of that now.

At some point during copy/pasting parts around rustfmt got hold of it, which makes the diff a bit noisier than I'd like. I can try to separate out the formatting changes if that's a problem.

[ChrisDenton]

Btw, in case it helps anyone test my working, here's the powershell commands I'm using to verify the difference this PR makes:

Z:\dllimport> @'
>> fn main() {
>>     println!("Hello World");
>> }
>> '@ > dllimport.rs
Z:\dllimport> rustc dllimport.rs
Z:\dllimport> dumpbin /disasm dllimport.exe | Select-String WriteConsoleW

  000000014000E395: E8 69 D3 00 00     call        WriteConsoleW
  000000014000E3F6: E8 08 D3 00 00     call        WriteConsoleW
WriteConsoleW:
  000000014001B703: FF 25 2F 09 00 00  jmp         qword ptr [__imp_WriteConsoleW]

Z:\dllimport> rustc +dllimport dllimport.rs
Z:\dllimport> dumpbin /disasm dllimport.exe | Select-String WriteConsoleW

  00000001400027BF: FF 15 93 88 01 00  call        qword ptr [__imp_WriteConsoleW]
  0000000140002855: FF 15 FD 87 01 00  call        qword ptr [__imp_WriteConsoleW]

I'm using the "Developer Powershell for VS 2019" but only so dumpbin is in the PATH. The rustc +dllimport is used for a custom rustup toolchain which points to a build with this PR applied.

[dtolnay]

Thanks!

[dtolnay]

@bors r+

[bors]

📌 Commit fc40aa0 has been approved by dtolnay

[klensy]

Is there any reason why u deleted this comments (and lower)?

[ChrisDenton]

Now that only Windows 7+ is supported the detailed version info seems redundant.

[bors]

⌛ Testing commit fc40aa0 with merge 92418ce...