rustc places an absolute address into a jump table for imported functions instead of a relative one

[CtrlZvi]

This code:

#![feature(libc, unicode)]
extern crate libc;
extern crate unicode;

#[cfg(target_family = "windows")]
#[allow(non_snake_case)]
#[link(name = "vccorlib")]
extern "C" {
    #[link_name = "?GetCmdArguments@Details@Platform@@YAPEAPEA_WPEAH@Z"]
    pub fn GetCmdArguments(argc : *mut libc::c_int) -> *const *const libc::wchar_t;
}

#[unstable]
pub fn get_command_arguments(argc : libc::c_int) -> (*const *const libc::wchar_t, libc::c_int) {
    let mut argc = argc;
    ( unsafe { GetCmdArguments(&mut argc) }, argc)
}

#[cfg(test)]
mod tests {
    use super::*;

    #[test]
    fn test_get_command_arguments() {
        get_command_arguments(0);
    }
}

rustc minimumrepro.rs --crate-name minimumrepro --crate-type lib -g --test --emit=dep-info,link -L "C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/lib/store/amd64"

should produce the following code (provided as a disassembly snippet):

...
000000000052CF18  jmp         qword ptr [6147d0h]  
000000000052CF1E  nop  
000000000052CF1F  nop  
...

But it instead produces the following code

...
000000000052CF18  jmp         qword ptr [0B416EEh]  
000000000052CF1E  nop  
000000000052CF1F  nop  
...

The difference is in the first entry of the jump table, which is the entry for the function explicitly mentioned in the source code. The incorrect value is caused by an absolute offset being written into the binary instead of a relative one. 0x52cf1e + 0x6147d0 = 0xb416ee.

Meta

rustc --version --verbose:
rustc 1.0.0-nightly (2fc8b1e 2015-03-07) (built 2015-03-08)
binary: rustc
commit-hash: 2fc8b1e
commit-date: 2015-03-07
build-date: 2015-03-08
host: x86_64-pc-windows-gnu
release: 1.0.0-nightly

Backtrace:

N/A

[vadimcn]

@CtrlZvi: Can't find this API in MSDN... Are you sure you've declared it correctly?

[CtrlZvi]

@vadimcn It's not documented in MSDN as its not part of the API. But it's an exported function in the store\amd64 version of vccorlib. It's called as part of the initialization of WinRT apps. I think I got the declaration correct, but maybe I got it wrong?

I copied the name from Dependency Walker (looking at "C:\Program Files\WindowsApps\Microsoft.VCLibs.120.00.Debug_12.0.21005.1_x64__8wekyb3d8bbwe\vccorlib120_app.dll" after installing Visual Studio 2013 and running a 64 bit of a sample WinRT Universal App):
Mangled: ?GetCmdArguments@Details@Platform@@YAPEAPEA_WPEAH@Z
UnMangled: wchar_t * * Platform::Details::GetCmdArguments(int *)

I confirmed through tracing through the DirectX WinRT Universal App sample that the function does mutate the input, which is how it returns the number of command line arguments.

If I change the #[link_name] then it fails to link, so the import library definitely provides the symbol as specified.

[vadimcn]

So how do I run this? Looks like you are trying to create a store app?
What specific problems are you seeing?

[CtrlZvi]

The issue can be seen without running, but I'll provide instructions for running at the bottom of this.
I am trying to use Rust to create a Store App.

When linking against import libraries for DLLs, what's imported is just a jmp instruction followed by a couple nop instructions. The jmp jumps to an address stored in the contents of a memory location that is addressed by relative offset to an entry in the import address table (IAT). For the above code, linked against the vccorlib import library for 64bit store applications, the jmp instruction for the Platform::Details::GetCmdArguments function winds up with an absolute offset into the IAT instead of a relative one. This causes at best an invalid access at runtime and worse jumping to a random point in memory and executing code. If the executable is patched to use a relative offset instead, then the program runs fine.

To run the code:

1. Compile the above code for testing being sure to specify the path to the 64-bit store version of the Visual Studio 2013 VC libraries as a linker path (defaults to C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib\store\amd64).

rustc minimumrepro.rs --crate-name minimumrepro --crate-type lib -g --test --emit=dep-info,link -L "C:/Program Files (x86)/Microsoft Visual Studio 12.0/VC/lib/store/amd64"

1. Copy vccorlib120_app.dll, msvcrp120_app.dll, and msvcr120_app.dll next to the test executable from C:\Program Files\WindowsApps\Microsoft.VCLibs.120.00_12.0.21005.1_x64__8wekyb3d8bbwe (the hash at the end might be different). If necessary use Visual Studio to create a run a sample 64bit Windows store app to install those libraries.
2. For each of the copied DLLs run link.exe /EDIT /APPCONTAINER:NO
3. Run the executable

[vadimcn]

Rustc-generated code looks correct, however the address on the import table stub is wrong. It's probably this linker bug.

[CtrlZvi]

Yep, that looks like the exact issue. Good find.

[vadimcn]

I've pinged maintainers, and the fix is now checked in. Unclear how soon it will show up in mingw-builds...

[CtrlZvi]

That's awesome. It looks like the bug had had a fix attached for a very long time with no traction. Thanks so much!

[CtrlZvi]

The MSVC beta of Rust 1.2 does not seem to have this issue.

[alexcrichton]

It looks like the bug has been fixed upstream and MSVC also fixes this, so at this point everything is in the pipeline. As a result I'm going to close this, nice investigation @vadimcn and @CtrlZvi!