Currently the Windows TLS destructor implementation is held together by hacks in the standard library but it'd be better to have proper compiler support instead. The library implementation is currently in this file: https://github.com/rust-lang/rust/blob/7ab5eb8fe7aee35aea8ed4aed8c34f6abd988cc5/library/std/src/sys/pal/windows/thread_local_key.rs
The short version is that, for #[cfg(target_thread_local)] platforms we need the p_thread_callback to be associated with register_keyless_dtor such that if register_keyless_dtor is used in the final binary then p_thread_callback will also be included. Currently this is done using a volatile load of the assassinated function but this hack is not recommended.
A similar thing is also necessary for the #[cfg(not(target_thread_local))] case. if register_dtor is used in the final binary then p_thread_callback will also needs including.
In you don't want to go digging around the linked file, here are the relevant definitions:
`#[cfg(target_thread_local)]`
unsafe fn register_keyless_dtor(t: *mut u8, dtor: unsafe extern "C" fn(*mut u8));
`#[cfg(not(target_thread_local))]`
unsafe fn register_dtor(key: &'static StaticKey);
#[link_section = ".CRT$XLB"]
static p_thread_callback: unsafe extern "system" fn(*mut (), u32, *mut ()) = on_tls_callback;
Making sure p_thread_callback is included with the register destructor function could be done in a few ways:
Object file
We could take advantage of object based linkage by writing a single object file containing both symbols. When put in a lib it'll ensure they're both included together. We would of course need some kind of attribute or magic symbol name to tell the compiler how to find these special symbols.
Probably not a good idea
COMDAT
The Windows COFF object format has IMAGE_COMDAT_SELECT_ASSOCIATIVE that allows associating one function with another. We could have some rustc attribute that std can use to annotate one symbol as being associated with another and then the compiler would emit the necessary comdat.
This is probably not a good idea because I'm not sure mixing COMDAT sections with special linker sections will work.
Currently the Windows TLS destructor implementation is held together by hacks in the standard library but it'd be better to have proper compiler support instead. The library implementation is currently in this file: https://github.com/rust-lang/rust/blob/7ab5eb8fe7aee35aea8ed4aed8c34f6abd988cc5/library/std/src/sys/pal/windows/thread_local_key.rs
The short version is that, for
#[cfg(target_thread_local)]platforms we need thep_thread_callbackto be associated withregister_keyless_dtorsuch that ifregister_keyless_dtoris used in the final binary thenp_thread_callbackwill also be included. Currently this is done using a volatile load of the assassinated function but this hack is not recommended.A similar thing is also necessary for the
#[cfg(not(target_thread_local))]case. ifregister_dtoris used in the final binary thenp_thread_callbackwill also needs including.In you don't want to go digging around the linked file, here are the relevant definitions:
Making sure
p_thread_callbackis included with the register destructor function could be done in a few ways:Object file
We could take advantage of object based linkage by writing a single object file containing both symbols. When put in a lib it'll ensure they're both included together. We would of course need some kind of attribute or magic symbol name to tell the compiler how to find these special symbols.
Probably not a good idea
COMDAT
The Windows COFF object format has
IMAGE_COMDAT_SELECT_ASSOCIATIVEthat allows associating one function with another. We could have some rustc attribute that std can use to annotate one symbol as being associated with another and then the compiler would emit the necessary comdat.This is probably not a good idea because I'm not sure mixing COMDAT sections with special linker sections will work.