Compiler support for Windows TLS destructors

[ChrisDenton]

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.

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:

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.

Object file

We could instead use old-fashioned (i.e. non-comdat) 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.

[bjorn3]

The object crate doesn't support IMAGE_COMDAT_SELECT_ASSOCIATIVE. Cg_clif can't implement this until object support it. Edit: Should have looked a bit further in the source code. It is supported by object after all. cranelift-object doesn't have an api for comdat support though, but I think it is possible to work around that and add the comdat after finalizing the ObjectModule.

[ChrisDenton]

After giving this some more thought, I think using a separate object/lib file is the most robust solution. I'm not sure that mixing comdat sections with magic linker sections is a good idea.