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.

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

Enable #[thread_local] for all windows-msvc targets #92042

Merged
merged 2 commits into from
Dec 19, 2021

Conversation

ChrisDenton
Copy link
Member

As it stands, #[thread_local] is enabled haphazardly for msvc. It seems all 64-bit targets have it enabled, but not 32-bit targets unless they're also UWP targets (perhaps because UWP was added more recently?). So this PR simply enables it for 32-bit targets as well. I can't think of a reason not to and I've confirmed by running tests locally which pass.

See also #91659

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Dec 17, 2021
@rust-highfive
Copy link
Collaborator

r? @nagisa

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive
Copy link
Collaborator

⚠️ Warning ⚠️

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 17, 2021
@@ -27,6 +27,7 @@ pub fn opts() -> TargetOptions {
// linking some libraries which require a specific agreement, so it may
// not ever be possible for us to pass this flag.
no_default_libraries: false,
has_elf_tls: true,
Copy link
Member

@nagisa nagisa Dec 17, 2021

Choose a reason for hiding this comment

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

I think this field wants a rename to something like has_thread_local or something of a similar nature?

EDIT: reading the issue, yeah it is fine to rename target fields.

Copy link
Member Author

Choose a reason for hiding this comment

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

has_thread_local sounds ok to me! If anybody wants to bikeshed the name I don't mind changing it again but it's probably not worth arguing about it too much 🙂.

Copy link
Member

Choose a reason for hiding this comment

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

Are we sure that this field is never used in some ELF-specific way?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hm, well if it is then it was wrong to use it for msvc targets. But I did do a search and the only place it's used (other than specs) is here:

if sess.target.has_elf_tls {
ret.insert((sym::target_thread_local, None));
}

As far as I understand it, Rust defers to LLVM for actually generating the TLS access (it uses the LLVM IR thread_local).

@nagisa
Copy link
Member

nagisa commented Dec 17, 2021

Hm, one thing that's curious to me is that we have a test ui/thread-local/tls.rs which only ignores emscripten targets and uses #[thread_local] unconditionally.

Can you confirm this test is run on Windows?

@nagisa nagisa added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 17, 2021
@ChrisDenton
Copy link
Member Author

ChrisDenton commented Dec 17, 2021

Yes it runs. But it succeeds regardless of if has_elf_tls is true or false. I'm confused. As a test I forced it to fail by appending assert!(false) so it's definitely being run.

EDIT EDIT: Hm, I think #[thread_local] always works but the associated cfg isn't enabled.

/// this target.
pub has_elf_tls: bool,
/// Flag indicating whether #[thread_local] is available for this target.
pub has_thread_local: bool,
Copy link
Member

Choose a reason for hiding this comment

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

Maybe call it has_object_thread_local? This indicates whether thread locals are supported by the used object file format, not whether thread locals in general are supported. thread_local!{} works even if this is false.

Copy link
Member

Choose a reason for hiding this comment

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

has_target_thread_local also makes sense. This matches the #[cfg(target_thread_local)] attribute whose value it controls.

Copy link
Member

Choose a reason for hiding this comment

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

has_target_thread_local also makes sense.

This is already in the context of Target though and many other fields don't have this prefix in target spec but has one as the cfg variable.

Some other options: has_static_thread_local (as in “static initailizers”), has_native_thread_local

@nagisa
Copy link
Member

nagisa commented Dec 18, 2021

@bors r+

I think it is fine if we rename the field again if has_thread_local turns out to be too ambiguous. At the very least it is no longer incorrect.

@bors
Copy link
Contributor

bors commented Dec 18, 2021

📌 Commit 391332c has been approved by nagisa

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Dec 18, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 19, 2021
…askrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#91141 (Revert "Temporarily rename int_roundings functions to avoid conflicts")
 - rust-lang#91984 (Remove `in_band_lifetimes` from `rustc_middle`)
 - rust-lang#92028 (Sync portable-simd to fix libcore build for AVX-512 enabled targets)
 - rust-lang#92042 (Enable `#[thread_local]` for all windows-msvc targets)
 - rust-lang#92071 (Update example code for Vec::splice to change the length)
 - rust-lang#92077 (rustdoc: Remove unused `collapsed` field)
 - rust-lang#92081 (rustdoc: Remove unnecessary `need_backline` function)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 4dbe966 into rust-lang:master Dec 19, 2021
@rustbot rustbot added this to the 1.59.0 milestone Dec 19, 2021
@ChrisDenton ChrisDenton deleted the msvc-static-tls branch December 19, 2021 16:05
@ChrisDenton
Copy link
Member Author

Should the naming discussion be continued on the original issue?

@nagisa
Copy link
Member

nagisa commented Dec 19, 2021

Seems reasonable to do so. Or in a new issue entirely.

@quininer
Copy link
Contributor

quininer commented Mar 8, 2022

I noticed this has a regression on i686-pc-windows-msvc + windows7. This results in an access violation when the program initializes tls.

Unfortunately I can't provide a minimal reproducible example, but I'm sure turning off has_thread_local fixes the problem. I've tried using rustc before that commit or compiling rustc with has_thread_local turned off, and they don't crash.

@ChrisDenton
Copy link
Member Author

@quininer oh dear, that means our CI tests aren't able to tell when this regresses. This will likely need to be reverted again.

But first would it be at all possible for you test this PR? No worries if not but it'd be nice to know if it helps your case or not.

@quininer
Copy link
Contributor

@ChrisDenton Sorry, due to COVID-19 I need to WFH, so there is no windows7 device can to test at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants