Skip to content

win7: load synch functions on demand #143598

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+28 −73
Open

win7: load synch functions on demand #143598

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions library/std/src/sys/pal/windows/c.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -188,6 +188,8 @@ unsafe extern "system" {
// These are loaded by `load_synch_functions`.
#[cfg(target_vendor = "win7")]
compat_fn_optional! {
pub static SYNCH_API: &CStr = c"api-ms-win-core-synch-l1-2-0";

pub fn WaitOnAddress(
address: *const c_void,
compareaddress: *const c_void,
Expand Down
99 changes: 26 additions & 73 deletions library/std/src/sys/pal/windows/compat.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,51 +23,6 @@ use crate::ffi::{CStr, c_void};
use crate::ptr::NonNull;
use crate::sys::c;

// This uses a static initializer to preload some imported functions.
// The CRT (C runtime) executes static initializers before `main`
// is called (for binaries) and before `DllMain` is called (for DLLs).
//
// It works by contributing a global symbol to the `.CRT$XCT` section.
// The linker builds a table of all static initializer functions.
// The CRT startup code then iterates that table, calling each
// initializer function.
//
// NOTE: User code should instead use .CRT$XCU to reliably run after std's initializer.
// If you're reading this and would like a guarantee here, please
// file an issue for discussion; currently we don't guarantee any functionality
// before main.
// See https://docs.microsoft.com/en-us/cpp/c-runtime-library/crt-initialization?view=msvc-170
#[cfg(target_vendor = "win7")]
#[used]
#[unsafe(link_section = ".CRT$XCT")]
static INIT_TABLE_ENTRY: unsafe extern "C" fn() = init;

/// Preload some imported functions.
///
/// Note that any functions included here will be unconditionally loaded in
/// the final binary, regardless of whether or not they're actually used.
///
/// Therefore, this should be limited to `compat_fn_optional` functions which
/// must be preloaded or any functions where lazier loading demonstrates a
/// negative performance impact in practical situations.
///
/// Currently we only preload `WaitOnAddress` and `WakeByAddressSingle`.
#[cfg(target_vendor = "win7")]
unsafe extern "C" fn init() {
// In an exe this code is executed before main() so is single threaded.
// In a DLL the system's loader lock will be held thereby synchronizing
// access. So the same best practices apply here as they do to running in DllMain:
// https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-best-practices
//
// DO NOT do anything interesting or complicated in this function! DO NOT call
// any Rust functions or CRT functions if those functions touch any global state,
// because this function runs during global initialization. For example, DO NOT
// do any dynamic allocation, don't call LoadLibrary, etc.

// Attempt to preload the synch functions.
load_synch_functions();
}

/// Helper macro for creating CStrs from literals and symbol names.
macro_rules! ansi_str {
(sym $ident:ident) => {{ crate::sys::compat::const_cstr_from_bytes(concat!(stringify!($ident), "\0").as_bytes()) }};
Expand Down Expand Up @@ -201,26 +156,47 @@ macro_rules! compat_fn_with_fallback {
/// Relies on the functions being pre-loaded elsewhere.
#[cfg(target_vendor = "win7")]
macro_rules! compat_fn_optional {
($(
(pub static $module:ident: &CStr = $name:expr; $(
$(#[$meta:meta])*
$vis:vis fn $symbol:ident($($argname:ident: $argtype:ty),*) $(-> $rettype:ty)?;
)+) => (
pub static $module: &CStr = $name;
$(
pub mod $symbol {
#[allow(unused_imports)]
use super::*;
use crate::ffi::c_void;
use crate::mem;
use crate::ptr::{self, NonNull};
use crate::ptr;
use crate::sync::atomic::{Atomic, AtomicPtr, Ordering};
use crate::sys::compat::Module;

pub(in crate::sys) static PTR: Atomic<*mut c_void> = AtomicPtr::new(ptr::null_mut());
const NOT_FOUND: *mut c_void = ptr::null_mut();
const NOT_LOADED: *mut c_void = ptr::without_provenance_mut(usize::MAX);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just checking my understanding -- this is assuming (reasonably) that there's no function pointer starting at usize::MAX?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I believe that would be impossible. On Windows at least a high bit on the would indicate a kernel pointer (which is unusable from user space), so it's outside of addressable memory. An alternative would be to use a low value (like, say, 1 or 2) because the first page is reserved as a guard against null pointer access.


pub(in crate::sys) static PTR: Atomic<*mut c_void> = AtomicPtr::new(NOT_LOADED);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes me wonder if we should implement AtomicPrimitive for all F: FnPtr(...) at some point. Though maybe that would hurt our ability to support a generalized "fits in u8/u32/u64 without padding" Atomic...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would love that! Assuming it's possible.


type F = unsafe extern "system" fn($($argtype),*) $(-> $rettype)?;

#[inline(always)]
fn load_from_module(module: Option<Module>) -> Option<F> {
unsafe {
static SYMBOL_NAME: &CStr = ansi_str!(sym $symbol);
if let Some(f) = module.and_then(|m| m.proc_address(SYMBOL_NAME)) {
PTR.store(f.as_ptr(), Ordering::Relaxed);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the thinking is it's OK to have multiple GetProcAddress calls if many threads race on the initialization?

https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getprocaddress doesn't note any synchronization requirements. Should we be worried about any kind of dynamic library loading during the GetProcAddress call that might need a release/acquire if it's called from some other thread (currently not added since we're Relaxed)? I guess the load itself is happening earlier when the module is initialized (Module::new below?).

Copy link
Member Author

@ChrisDenton ChrisDenton Jul 13, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, GetModuleHandle does the loading. GetProcAddress just reads the address from a lookup table afterwards.

In any case, all dynamic library loading takes a loader lock that synchronises the whole operation. So everything is loaded sequentially. It's a much stronger barrier than any atomic so we don't really need any cross-thread synchronisation ourselves, we just have to make sure our own read/writes are atomic.

Some(mem::transmute(f))
} else {
PTR.store(NOT_FOUND, Ordering::Relaxed);
None
}
}
}

pub fn option() -> Option<F> {
NonNull::new(PTR.load(Ordering::Relaxed)).map(|f| unsafe { mem::transmute(f) })
match PTR.load(Ordering::Relaxed) {
NOT_FOUND => None,
NOT_LOADED => load_from_module(unsafe { Module::new($module) }),
f => Some(unsafe { mem::transmute(f) })
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: could you add a safety comment on the transmutes? (In particular describing why the Option transmute is OK)

}
}
}
#[inline]
Expand All @@ -230,26 +206,3 @@ macro_rules! compat_fn_optional {
)+
)
}

/// Load all needed functions from "api-ms-win-core-synch-l1-2-0".
#[cfg(target_vendor = "win7")]
pub(super) fn load_synch_functions() {
fn try_load() -> Option<()> {
use crate::sync::atomic::Ordering;
const MODULE_NAME: &CStr = c"api-ms-win-core-synch-l1-2-0";
const WAIT_ON_ADDRESS: &CStr = c"WaitOnAddress";
const WAKE_BY_ADDRESS_SINGLE: &CStr = c"WakeByAddressSingle";

// Try loading the library and all the required functions.
// If any step fails, then they all fail.
let library = unsafe { Module::new(MODULE_NAME) }?;
let wait_on_address = library.proc_address(WAIT_ON_ADDRESS)?;
let wake_by_address_single = library.proc_address(WAKE_BY_ADDRESS_SINGLE)?;

c::WaitOnAddress::PTR.store(wait_on_address.as_ptr(), Ordering::Relaxed);
c::WakeByAddressSingle::PTR.store(wake_by_address_single.as_ptr(), Ordering::Relaxed);
Some(())
}

try_load();
}
Loading