std: detect stack overflows in TLS destructors on UNIX

[joboet]

Fixes #111272.

With #127912 merged, we now have all the infrastructure in place to support stack overflow detection in TLS destructors. This was not possible before because the signal stack was freed in the thread main function, thus a SIGSEGV afterwards would immediately crash. And on platforms without native TLS, the guard page address was stored in an allocation freed in a TLS destructor, so would not be available. #127912 introduced the local_pointer macro which allows storing a pointer-sized TLS variable without allocation and the thread_cleanup runtime function which is called after all other code managed by the Rust runtime. This PR simply moves the signal stack cleanup to the end of thread_cleanup and uses local_pointer to store every necessary variable. And so, everything run under the Rust runtime is now properly protected against stack overflows.

[rustbot]

r? @Amanieu

rustbot has assigned @Amanieu.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[bors]

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

[Amanieu]

The logic was a little hard to follow in the code, but after looking at it for a bit it makes sense.

@bors r+

[bors]

📌 Commit 6620e2b has been approved by Amanieu

It is now in the queue for this repository.

[jieyouxu]

I think this failed in rollup: #135906 (comment)

testing: silent-thread
testing: loud-thread
testing: silent-thread-tls
--- stderr -------------------------------

thread 'main' panicked at C:\a\rust\rust\tests\ui\runtime\out-of-stack.rs:71:5:
assertion failed: !status.success()
------------------------------------------

failures:
    [ui] tests\ui\runtime\out-of-stack.rs

@bors r-

[joboet]

I'm completely lost as to why this would fail. The stack overflow clearly gets detected properly (the correct message is printed), but the program still reports a success. Do stack overflows in TLS callback functions not lead to an abort?

@ChrisDenton you know a lot more about Windows than I do, have you got any ideas?

[ChrisDenton]

Hmm.. the stack overflow is happening while the thread is already exiting? I'm pretty sure in that case the exiting thread just returns the original exit code rather than changing it. If that's indeed the case (I'll double check when I have a moment) then I don't think there's anything we can reasonably do about it.

[ChrisDenton]

Oh right, now that I'm more awake I think I can explain what's going on.

Thread locals drops are run via a TLS callback function. When running the callback, any exceptions thrown (such as the stack overflow exception) will be essential caught and discarded. The callback function will end and further TLS callback functions won't run but neither will the normal exception behaviour.

However, I'm finding it hard to find any official docs about exceptions in TLS callbacks.

We do add a Vectored Exception Handler to print the stack overflow message. This should still happen because the handler is called before unwinding, etc.

[joboet]

Mmmh. I guess this was always the case and should be fine... I'll just skip the test.