Skip to content

Compiler support for Windows TLS destructors #123907

Open
@ChrisDenton

Description

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.

Metadata

Assignees

No one assigned

    Labels

    A-thread-localsArea: Thread local storage (TLS)C-enhancementCategory: An issue proposing an enhancement or a PR with one.O-windowsOperating system: WindowsT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions