Skip to content
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

Jump to bottom

Windows TLS destructors don't run in a statically linked binary #28111

Closed
nagisa opened this issue Aug 30, 2015 · 2 comments
Closed

Windows TLS destructors don't run in a statically linked binary #28111

nagisa opened this issue Aug 30, 2015 · 2 comments
Labels
O-windows Operating system: Windows

Comments

@nagisa
Copy link
Member

nagisa commented Aug 30, 2015

On -msvc TLS destructors do not appear to be run at all.

On -gnu TLS destructors appear to run when a non-main thread exits (as expected) or std::process:exit is called (es expected), but not run when main thread is terminated normally (by returning from fn main; not expected).

Various variations of this/this program has been used for testing.

cc @retep998 who did the testing
@nagisa
Copy link
Member Author

nagisa commented Aug 31, 2015

// The linker must not discard p_thread_callback_base. (We force a reference to this variable with a linker /INCLUDE:symbol pragma to ensure that.) If this variable is discarded, the OnThreadExit function will never be called.

and

//.CRT section is merged with .rdata on x64 so it must be constant data.
#pragma const_seg(".CRT$XLB")
// When defining a const variable, it must have external linkage to be sure the linker doesn't discard it.

are comments from the chromium’s TLS impl pointing towards something that might be missing from our implementation: we do not make sure data is constant on x64 and we do not make sure our symbol is \INCLUDEd.

@retep998 retep998 mentioned this issue Aug 31, 2015
Merged
@alexcrichton alexcrichton mentioned this issue Aug 31, 2015
Merged
@alexcrichton
Copy link
Member

The bug here for threads in general specifically has to do with linkage, and I'm about to fix that in #28130, and for the main thread I've opened #28129 as it's not specific to Windows unfortunately.

For now I'm gonna recategorize this as "TLS destructors don't run in a statically linked binary on Windows"

@alexcrichton alexcrichton changed the title Windows TLS destructors are broken Windows TLS destructors don't run in a statically linked binary Aug 31, 2015
@alexcrichton alexcrichton added the O-windows Operating system: Windows label Aug 31, 2015
alexcrichton added a commit to alexcrichton/rust that referenced this issue Sep 1, 2015
@alexcrichton
std: Run TLS destructors in a statically linked binary
9a3acec 
Running TLS destructors for a MSVC Windows binary requires the linker doesn't
elide the `_tls_used` or `__tls_used` symbols (depending on the architecture).
This is currently achieved via a `#[link_args]` hack but this only works for
dynamically linked binaries because the link arguments aren't propagated to
statically linked binaries.

This commit alters the strategy to instead emit a volatile load from those
symbols so LLVM can't elide it, forcing the reference to the symbol to stay
alive as long as the callback function stays alive (which we've made sure of
with the `#[linkage]` attribute).

Closes rust-lang#28111
bors added a commit that referenced this issue Sep 1, 2015
@bors
Auto merge of #28130 - alexcrichton:fix-msvc-static-tls-dtor, r=brson
cb9323e 
Running TLS destructors for a MSVC Windows binary requires the linker doesn't
elide the `_tls_used` or `__tls_used` symbols (depending on the architecture).
This is currently achieved via a `#[link_args]` hack but this only works for
dynamically linked binaries because the link arguments aren't propagated to
statically linked binaries.

This commit alters the strategy to instead emit a volatile load from those
symbols so LLVM can't elide it, forcing the reference to the symbol to stay
alive as long as the callback function stays alive (which we've made sure of
with the `#[linkage]` attribute).

Closes #28111
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
O-windows Operating system: Windows
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@alexcrichton @nagisa