Eagerly run TLS destructors to properly handle stack overflows

[joboet]

Fixes #109785 for UNIX systems with native TLS support.

By eagerly running the TLS destructors while the stack overflow handler is still active, stack overflows are now correctly reported. Since the destructors are invoked only after any user code has finished running, there should be no observable differences in behaviour. Also note that TLS destructors still work as expected for threads not created by std.

This also removes the specialized destructor registration implementations on Linux and macOS. Going through a native TLS key probably brings no noticeable performance degradations, and it simplifies the code considerably.

[rustbot]

r? @thomcc

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[joboet]

It seems this doesn't work on Linux (I could only test on macOS). My current guess is that this fails because of some sigaltstack thing...

Resolved it by running the destructors eagerly.

[thomcc]

@rustbot author

[joboet]

@rustbot ready

[rust-log-analyzer]

The job x86_64-gnu-llvm-14 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

running 16 tests
error: test failed, to rerun pass `--lib`

Caused by:
  process didn't exit successfully: `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/deps/proc_macro_srv-9ede8e52d0dfb500 -Z unstable-options --format json` (signal: 11, SIGSEGV: invalid memory reference)
.............Build completed unsuccessfully in 0:25:47

[joboet]

@rustbot author

[JohnCSimon]

@joboet

ping from triage - can you post your status on this PR? There hasn't been an update in a few months. Thanks!

FYI: when a PR is ready for review, send a message containing
@rustbot ready to switch to S-waiting-on-review so the PR is in the reviewer's backlog.

[joboet]

I'm still completely lost as to what the issue here might be, but I'll make sure to change the status again once I've found it. Until then I'd like to keep this open if it's alright with you, just so that the tracking issue has an open PR to link to.

[bors]

☔ The latest upstream changes (presumably #115753) made this pull request unmergeable. Please resolve the merge conflicts.

[joboet]

I'm marking this as a draft until #116850 is merged, which should simplify the changes here, while preserving the platform-specific parts.

[joboet]

I've found a better way to implement this and will put that up after #126953 is merged.