Windows MSVC/GNU function pointer check issues

[dybucc]

Windows targets under MSVC and GNU currently skip function pointer checks in ctest.

The issue is two-fold. Linking in MSVC works just fine. It's the function pointers that end up resolving unequal. Linking in GNU fails. It reports undefined references to certain library symbols.

More information may be added to this issue later on.

[mansiverma897993]

@dybucc I have raise PR #5229 plz look at once and lemme know if any changes required!1

[tgross35]

Context for this is starting at #5059 (comment)

[mansiverma897993]

Hi @tgross35,

Previously, all function pointer checks on Windows were skipped (cfg.skip_fn_ptrcheck(|_| true)) in #5059 with the comment // FIXME(windows): All functions point to the wrong addresses?.

The root cause was that when taking function addresses for DLL-imported functions on Windows, both the Rust and C compilers generate distinct local Import Address Table (IAT) jump stubs (ff 25 / jmp instructions). Because of these separate stubs, the function pointer values resolved to different local addresses, causing the comparisons to fail.

To resolve this:

1. IAT Jump Stub Resolution: Added a resolve helper in check_same_fn_ptr (inside ctest/templates/test.rs). On x86/x86_64 Windows, it checks the instruction bytes at the pointer address for the 0xff 0x25 opcode, reads the displacement/target address, and dereferences it to compare the underlying DLL export address directly. This allows the pointers to be compared correctly.
2. Re-enabled Checks: Removed the catch-all skip in libc-test/build.rs so that we verify function pointer signatures on Windows too. We only skip ctime and difftime now, as they are inline functions in the MSVC CRT headers and resolve to local wrapper functions rather than DLL exports.
3. Winsock Library Linkage: Linked -lws2_32 for Windows GNU targets in ctest/src/runner.rs to fix undefined reference link errors for socket functions.
4. MSVC Warning C4197: Disabled MSVC warning C4197 ("top-level volatile in cast is ignored") via /wd4197 in ctest/src/runner.rs as it was causing build failures under MSVC's /WX (warnings as errors).

[tgross35]

Why are the IAT stubs different, do they also differ across invocations?

Also, it feels like you may have passed along AI output. Please handwrite all communication, we are humans and would like to talk to other humans rather than bots.

[tgross35]

Hey @Fulgen301 @mati865 maybe you're able to give a hint about what's going on here. On both windows-msvc and windows-gnu, attempting to enable the function pointer tests give results like:

bad `isalpha` function pointer: rust: 140730738084544 != c 140697062605053
bad `iscntrl` function pointer: rust: 140730738145152 != c 140697062605065
bad `isdigit` function pointer: rust: 140730737772160 != c 140697062605071
bad `isgraph` function pointer: rust: 140730738189088 != c 140697062605077
bad `islower` function pointer: rust: 140730738153744 != c 140697062605083
bad `isprint` function pointer: rust: 140730738176784 != c 140697062605089
bad `ispunct` function pointer: rust: 140730738083920 != c 140697062605095
bad `isspace` function pointer: rust: 140730737771616 != c 140697062605101
bad `isupper` function pointer: rust: 140730738084128 != c 140697062605107
bad `isxdigit` function pointer: rust: 140730738084336 != c 140697062605275
bad `isblank` function pointer: rust: 140730738186768 != c 140697062605059
bad `tolower` function pointer: rust: 140730737785936 != c 140697062605221
bad `toupper` function pointer: rust: 140730738101376 != c 140697062605227
bad `qsort` function pointer: rust: 140730738002304 != c 140697062604693
bad `qsort_s` function pointer: rust: 140730738000736 != c 140697062605131
bad `fopen` function pointer: rust: 140730738299264 != c 140697062604633

The test has code like this:

#if defined(__cplusplus)
    #define CTEST_ALIGNOF(T) alignof(T)
    #define CTEST_EXTERN extern "C"
#else
    #define CTEST_ALIGNOF(T) _Alignof(T)
    #define CTEST_EXTERN
#endif

typedef void (*ctest_void_func)(void);

CTEST_EXTERN ctest_void_func ctest_foreign_fn__dup2(void) {
    return (ctest_void_func)_dup2;
}

Called via:

    pub fn ctest_foreign_fn_dup2() {
        extern "C" {
            fn ctest_foreign_fn__dup2() -> unsafe extern "C" fn();
        }
        let actual = unsafe { ctest_foreign_fn__dup2() } as u64;
        let expected = dup2 as *const () as u64;
        check_same(actual, expected, "`dup2` function pointer");
    }

These get built then linked, and check_same prints that failure if the pointers don't match. The goal is to make sure that libc bindings are pointing to the same address as whatever you get when you build a C library and usually this works, but on Windows we get the failures. Everything seems to link fine so I don't think it's an issue with inline functions.

There's a sample run at #5301, and the generated test files can be downloaded from the CI summary page if needed.

I have no idea what to make of the LLM-y response above.

[mati865]

I have no idea what to make of the LLM-y response above.

Sorry, I'm not going to bother reading that. The same goes for the LLM made PR.

You are comparing the real function versus dllimport thunk. I have tested it with these steps:

❯ WINEPATH=/opt/llvm-mingw/llvm-mingw-ucrt/x86_64-w64-mingw32/bin cargo test --target x86_64-pc-windows-gnullvm --workspace --no-default-features -- ctest

❯ WINEPATH=/opt/llvm-mingw/llvm-mingw-ucrt/x86_64-w64-mingw32/bin winedbg --gdb target/x86_64-pc-windows-gnullvm/debug/deps/ctest-4fb112299a90c9a3.exe

Wine-gdb> b ctest::generated_tests::ctest_foreign_fn_dup2
Breakpoint 1 at 0x140007fd4: file target/x86_64-pc-windows-gnullvm/debug/build/libc-test-0dc83b612976c88a/out/ctest_output.rs, line 9284.
Wine-gdb> c
Continuing.

Breakpoint 1, ctest::generated_tests::ctest_foreign_fn_dup2 () at target/x86_64-pc-windows-gnullvm/debug/build/libc-test-0dc83b612976c88a/out/ctest_output.rs:9284
9284            let actual = unsafe { ctest_foreign_fn__dup2() } as u64;
Wine-gdb> n
9285            let expected = dup2 as *const () as u64;
Wine-gdb> n
9286            check_same(actual, expected, "`dup2` function pointer");
Wine-gdb> i locals
expected = 5369112400
actual = 123145278410880

# now convert the addresses to hex, they are 0x140062750 and 0x6FFFFE935080

Wine-gdb> i functions 0x140062750
All functions matching regular expression "0x140062750":
Wine-gdb> i symbol 0x140062750
_dup2 in section .text of /home/mateusz/Projects/libc/target/x86_64-pc-windows-gnullvm/debug/deps/ctest-4fb112299a90c9a3.exe
_dup2 in section .text of /home/mateusz/Projects/libc/target/x86_64-pc-windows-gnullvm/debug/deps/ctest-4fb112299a90c9a3.exe
Wine-gdb> i symbol 0x6FFFFE935080
No symbol matches 0x6FFFFE935080.

Wine-gdb> disas 0x140062750
Dump of assembler code for function _dup2:
   0x0000000140062750 <+0>:     jmp    *0x122c2(%rip)        # 0x140074a18 <__imp__dup2>
   0x0000000140062756 <+6>:     int3
   0x0000000140062757 <+7>:     int3
   0x0000000140062758 <+8>:     int3
   0x0000000140062759 <+9>:     int3
   0x000000014006275a <+10>:    int3
   0x000000014006275b <+11>:    int3
   0x000000014006275c <+12>:    int3
   0x000000014006275d <+13>:    int3
   0x000000014006275e <+14>:    int3
   0x000000014006275f <+15>:    int3
End of assembler dump.
Wine-gdb> disas 0x6FFFFE935080
❌ No function contains specified address.
Wine-gdb> x/15i 0x6FFFFE935080
   0x6ffffe935080:      push   %r15
   0x6ffffe935082:      push   %r14
   0x6ffffe935084:      push   %r13
   0x6ffffe935086:      push   %r12
   0x6ffffe935088:      push   %rbp
   0x6ffffe935089:      push   %rdi
   0x6ffffe93508a:      push   %rsi
   0x6ffffe93508b:      push   %rbx
   0x6ffffe93508c:      sub    $0x68,%rsp
   0x6ffffe935090:      mov    %ecx,%ebp
   0x6ffffe935092:      mov    %edx,%r12d
   0x6ffffe935095:      testb  $0x8,0x6f144(%rip)        # 0x6ffffe9a41e0
   0x6ffffe93509c:      jne    0x6ffffe9352d8
   0x6ffffe9350a2:      cmp    %r12d,%ebp
   0x6ffffe9350a5:      jge    0x6ffffe9351e0

Now, for the extra fun: in case of windows-gnu* Rust relies on the linker to decide whether to use import thunk or link the function directly: https://github.com/rust-lang/rust/blob/79a4b003dd31ab70729f19215aa13d1e68d86fb6/compiler/rustc_codegen_llvm/src/callee.rs#L143. Now if we compare windows-gnu vs windows-gnullvm:

❯ WINEPATH=/opt/llvm-mingw/llvm-mingw-ucrt/x86_64-w64-mingw32/bin cargo test --target x86_64-pc-windows-gnullvm --workspace --no-default-features -- ctest 2>&1 | rg 'bad `' | wc -l
96

❯ cargo test --target x86_64-pc-windows-gnu --workspace --no-default-features -- ctest 2>&1 | rg 'bad `' | wc -l
98

Fun!

I diffed them and windows-gnullvm didn't report ctime and difftime, so let's see gdb:

❯ WINEPATH=/opt/llvm-mingw/llvm-mingw-ucrt/x86_64-w64-mingw32/bin winedbg --gdb target/x86_64-pc-windows-gnullvm/debug/deps/ctest-4fb112299a90c9a3.exe

Wine-gdb> b ctest::generated_tests::ctest_foreign_fn_ctime
Breakpoint 1 at 0x14000b064: file target/x86_64-pc-windows-gnullvm/debug/build/libc-test-0dc83b612976c88a/out/ctest_output.rs, line 9014.
Wine-gdb> c
Continuing.

Breakpoint 1, ctest::generated_tests::ctest_foreign_fn_ctime () at target/x86_64-pc-windows-gnullvm/debug/build/libc-test-0dc83b612976c88a/out/ctest_output.rs:9014
9014            let actual = unsafe { ctest_foreign_fn__ctime() } as u64;
Wine-gdb> n
9015            let expected = ctime as *const () as u64;
Wine-gdb> n
9016            check_same(actual, expected, "`ctime` function pointer");
Wine-gdb> i locals
expected = 5369114864
actual = 5369114864

Wine-gdb> disas 5369114864
Dump of assembler code for function ctime:
   0x00000001400630f0 <+0>:     jmp    *0x11ca2(%rip)        # 0x140074d98 <__imp__ctime64>
   0x00000001400630f6 <+6>:     int3
   0x00000001400630f7 <+7>:     int3
   0x00000001400630f8 <+8>:     int3
   0x00000001400630f9 <+9>:     int3
   0x00000001400630fa <+10>:    int3
   0x00000001400630fb <+11>:    int3
   0x00000001400630fc <+12>:    int3
   0x00000001400630fd <+13>:    int3
   0x00000001400630fe <+14>:    int3
   0x00000001400630ff <+15>:    int3
End of assembler dump.

Um, LLD used import thunk for both. How about LD?

❯ winedbg --gdb target/x86_64-pc-windows-gnu/debug/deps/ctest-0efb1d1462f2c818.exe

Wine-gdb> b 9016
Breakpoint 1 at 0x14000e02d: file target/x86_64-pc-windows-gnu/debug/build/libc-test-5ce1861fb15eaed2/out/ctest_output.rs, line 9016.
Wine-gdb> c
Continuing.

Breakpoint 1, ctest::generated_tests::ctest_foreign_fn_ctime () at target/x86_64-pc-windows-gnu/debug/build/libc-test-5ce1861fb15eaed2/out/ctest_output.rs:9016
9016            check_same(actual, expected, "`ctime` function pointer");
Wine-gdb> i locals
expected = 5369508440
actual = 536950836

Wine-gdb> disas 5369508440
Dump of assembler code for function ctime:
   0x00000001400c3258 <+0>:     jmp    *0x4c4ba(%rip)        # 0x14010f718 <__imp_ctime>
   0x00000001400c325e <+6>:     nop
   0x00000001400c325f <+7>:     nop
End of assembler dump.
Wine-gdb> disas 5369508368
Dump of assembler code for function _ctime64:
   0x00000001400c3210 <+0>:     jmp    *0x4c4ba(%rip)        # 0x14010f6d0 <__imp__ctime64>
   0x00000001400c3216 <+6>:     nop
   0x00000001400c3217 <+7>:     nop
End of assembler dump.

Right...
MSVCRT vs UCRT, or difference in how both linkers decided to add import thunks perhaps?

Edit: added missing link to rustc.

[tgross35]

Wow, thanks for doing a complete deep dive on this. Is there some way we can get the same behavior from both C and Rust? Or would comparing the return value of LoadLibrary/GetProcAddress give us the expected behavior?

[mati865]

Looking at mingw-w64 headers I see these functions (didn't check them all) are declared without dllimport, so perhaps the best solution would be rustc feature to skip dllimport. An alternative could be creating your own declarations with dllimport, but that sounds bad.
I'm not familiar with Win32 API enough to speak for getProcAddress.

[Fulgen301]

Now, for the extra fun: in case of windows-gnu* Rust relies on the linker to decide whether to use import thunk or link the function directly:

This feels...just wrong.

Looking at mingw-w64 headers I see these functions (didn't check them all) are declared without dllimport

That seems to be a mingw deficiency / difference - Windows correctly declares them as dllimport:

Header

_Check_return_ _ACRTIMP int __cdecl _isctype(_In_ int _C, _In_ int _Type);
_Check_return_ _ACRTIMP int __cdecl _isctype_l(_In_ int _C, _In_ int _Type, _In_opt_ _locale_t _Locale);
_Check_return_ _CRT_JIT_INTRINSIC _ACRTIMP int __cdecl isalpha(_In_ int _C);
_Check_return_ _ACRTIMP int __cdecl _isalpha_l(_In_ int _C, _In_opt_ _locale_t _Locale);
_Check_return_ _CRT_JIT_INTRINSIC _ACRTIMP int __cdecl isupper(_In_ int _C);
_Check_return_ _ACRTIMP int __cdecl _isupper_l(_In_ int _C, _In_opt_ _locale_t _Locale);
_Check_return_ _CRT_JIT_INTRINSIC _ACRTIMP int __cdecl islower(_In_ int _C);
_Check_return_ _ACRTIMP int __cdecl _islower_l(_In_ int _C, _In_opt_ _locale_t _Locale);

, where _ACRTIMP is

#ifndef _ACRTIMP
    #if defined _CRTIMP && !defined _VCRT_DEFINED_CRTIMP
        #define _ACRTIMP _CRTIMP
    #elif !defined _CORECRT_BUILD && defined _DLL
        #define _ACRTIMP __declspec(dllimport)
    #else
        #define _ACRTIMP
    #endif
#endif

aka "If _DLL is defined (the program is built with dynamic runtime libraries instead of statically linking them), use dllimport."

dllimport context

Context: __declspec(dllimport) and import libraries exist because of the way C and C++ programs are built - if you just call a function, the compiler generates a relative call like it would with any other function. When it comes to linking and that function comes from a DLL, the linker can't replace that call with a indirect call to the imported pointer because that'd require changing the opcode and the linker isn't a compiler (at least not in the classical model). Thus the import lib contains a thunk Foo that contains an indirect jump to the imported pointer __imp_Foo. With __declspec(dllimport) the compiler knows it's an import from a DLL and generates an indirect call to __imp_Foo directly.

(Import libraries themselves are just static libraries that may contain other code, but that's a niche usage.)

Is there some way we can get the same behavior from both C and Rust?

In theory taking the address of a dllimported function should yield the address of the actual function and not the dllimport thunk.

I think the problem is

libc/src/windows/mod.rs

Line 284 in a1fcda2

extern "C" {

- an extern block without a #[link] attribute generates calls to static functions, whereas an extern block with #[link(name = "foo")] generates dllimport calls because the default kind is dylib. As libc doesn't have that, it generates calls to the dllimport thunk, which won't compare equal to the function C sees.

See https://rust.godbolt.org/z/41ecoeTGG - uncomment / comment the attribute to see the codegen differences.

Adding a link attribute if crt-static isn't defined should help with that.

[tgross35]

A link attribute cut down on the list for win-msvc 🎉 https://github.com/rust-lang/libc/actions/runs/29916781201/job/88912415213?pr=5301#step:6:360 are these remaining symbols defined in a different library?

bad `strcpy` function pointer: rust: 140699571712527 != c 140734375776240
bad `strcat` function pointer: rust: 140699571712515 != c 140734375776080
bad `strcmp` function pointer: rust: 140699571712521 != c 140734375776448
bad `strchr` function pointer: rust: 140699571715723 != c 140734169324464
bad `strrchr` function pointer: rust: 140699571715741 != c 140734169324608
bad `strstr` function pointer: rust: 140699571715729 != c 140734169324928
bad `strlen` function pointer: rust: 140699571712533 != c 140734375776576
bad `memchr` function pointer: rust: 140699571715705 != c 140734169340256
bad `memcmp` function pointer: rust: 140699571715711 != c 140734169346064
...

I'm not sure how this should interact with #5265. It would be nice if we had a per-function dllimport like the C version does.

[Fulgen301]

are these remaining symbols defined in a different library?

str* and mem* are in vcruntime, the socket functions in ws2_32, I'll look more into the others.

It might be helpful to have the tests determine the module handle for that address via GetModuleHandleExW(GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS | GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT) and then print the module filename for that handle; the import thunks are statically linked into the executable whereas the real addresses are from the respective DLLs.

I'm not sure how this should interact with #5265. It would be nice if we had a per-function dllimport like the C version does.

Yea, the interactions between #[link] and extern blocks, especially that the docs allow

#[link(name = "foo")]
unsafe extern "C" {
    fn foo();
}

to be the same as

#[link(name = "foo")]
unsafe extern "C" {}

unsafe extern "C" {
    fn foo();
}

despite the two having different meanings on some platforms is quite unfortunate. The constructs are currently used as

1. link to function
2. link to library
3. link to function from this library

, and there is no guarantee 3. is equivalent to 1. + 2.

I don't think #5265 as-is is a good idea in light of that.

[dybucc]

I think the problem is

libc/src/windows/mod.rs

Line 284 in a1fcda2

extern "C" {

- an extern block without a #[link] attribute generates calls to static functions, whereas an extern block with #[link(name = "foo")] generates dllimport calls because the default kind is dylib. As libc doesn't have that, it generates calls to the dllimport thunk, which won't compare equal to the function C sees.

@Fulgen301 When you say that it generates calls to the dllimport thunk, you mean
that when attempting to link statically, we're calling into the address of the
literal assembly that woud actually jump to the slot in the IAT where the
address of the external DLL's function is loaded at runtime, instead of straight
into the slot in the IAT?

despite the two having different meanings on some platforms is quite unfortunate. The constructs are currently used as

1. link to function
2. link to library
3. link to function from this library

, and there is no guarantee 3. is equivalent to 1. + 2.

So maybe this needs either further discussion in rust-lang/rustc and possibly
merits modifications to the Linkage section in the Reference?

[dybucc]

I've been perusing the rust-lang/rust issue tracker and have found a potential
solution. Before that, though, some background. If you already know about RFC
1717, Solutions gets straight to the point.

RFC 1717 introduced the kind specifier to the link attribute. This RFC was
originally motivated by this exact scenario in Windows; Having the compiler
produce the right codegen for symbols that were sourced from a separate DLL. The
proposal doesn't explicitly mention the semantics of unannotated extern
blocks, but one can infer certain things. If we look at the Drawbacks section,
it is mentioned that static linkage is "strongly favored" in compiler internals,
which makes this explicit annotation a need for any object file linking to a
DLL.

The alternative @tgross35 mentions for annotating each individual item with
dllimport instead of having the entire block be annotated with both the
library name and the linkage kind, was also discussed in the afore mentioned
RFC. The drawbacks mentioned in the proposal would not affect our usecase
because we know well in advance whether Windows is expecting some symbol to come
from a DLL or not, but the fact this is not a generalized assumption and
cfg_attr would be needed in other scenarios makes me think proposing this may
not be a good idea. It would also imply having a Windows-specific attribute,
which seems like a bit much.

For further background, see issue rust-lang/rust#27438. It's a long thread and
you're probably best off starting out in either one of this or
this comment. Prior comments are sort of relevant, but they also
discuss compiler plugins (which haven't been a thing for quite a while now.)

Solutions (maybe?)

Issue rust-lang/rust#132061 proposes the possibility for the link attribute to
be capable of specifying the kind without necessarily specifying the name. I
have not seen any associated PoC implementation, so maybe this is not as viable
as one would think. It hasn't gained any traction ever since it was opened two
years ago, though. Though the same author of that issue commented on a way to
possibly have this on stable (though I'd wager that's a major hack) here. This
also discusses potentially renaming the link's name specifier, which should
leave the dllimport storage class codegen intact. That, though, would mean that
rust-lang/libc's build script would have to detect whether the target is an MSVC
target, so that we can rename the library name. I could be misinterpreting
things, though, as it's been a few hours of reading through this (tired.)

Another solution goes through ensuring that we annotate the extern block with
the link attribute only when testing. Not having the link attribute
currently doesn't stop things from working outside ctest's function pointer
comparisons. This makes rust-lang/rust#5265 still viable, as we can gate the
link attribute behind a cfg_attr that is exposed only when libc-test is
running. Note, though, that it seems linking to extern statics still seems to
be a pain point in MSVC targets, but I don't think this greatly affects
rust-lang/libc's usecase.

And I think that's it. I believe to have gone through all issues in this
codesearch and what I considered to be relatively viable solutions include only
the above.

I do believe the Rust Reference may need to further specify this is in a little
blue card note, but that's not a rust-lang/libc concern.

[tgross35]

rust-lang/rust#132061 indeed sounds like the best solution here, @ChrisDenton is it just waiting on lang or did other problems come up? We can nominate if it's just the former.

I think that at this time we can take a fix specifying the link kind and name. With respect to #5265, for 1.0 I'd be fine removing link attributes on all non-windows platforms and documenting that they'll be going away on Windows too. (Assuming 1.0 is ready before bare_link_kind.)