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

Do not unwind on Windows with panic=abort #46057

Open
Zoxc opened this issue Nov 17, 2017 · 7 comments
Open

Do not unwind on Windows with panic=abort #46057

Zoxc opened this issue Nov 17, 2017 · 7 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. O-windows Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@Zoxc
Copy link
Contributor

Zoxc commented Nov 17, 2017

Currently we use the ud2 instruction to abort the process. This unwinds the stack which we want to avoid. We also need to ensure that the abort mechanism triggers JIT debuggers (see #46056).

@Zoxc Zoxc added the O-windows Operating system: Windows label Nov 17, 2017
@retep998
Copy link
Member

ud2 causes an SEH exception. While SEH exceptions and Rust panics use the same underlying mechanism, they have different personality functions and don't conflict. An SEH exception does not cause Rust destructors to fire and is not caught by catch_panic. Rust will always emit uwtable for all functions regardless of whether the function is capable of unwinding due to the ability of SEH exceptions to occur anywhere and at any time. Causing an SEH exception which is not caught is how the JIT debugger is triggered!

@Zoxc
Copy link
Contributor Author

Zoxc commented Nov 21, 2017

The point is that ud2 causes unwinding. The problematic case is if Rust code is called from other code which catches all SEH exceptions and resumes execution into Rust code.

@XAMPPRocky XAMPPRocky added C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 19, 2018
@steveklabnik
Copy link
Member

Triage: not sure what the status of this is, honestly.

@retep998
Copy link
Member

retep998 commented Jul 12, 2020

The main blocker as far as I can tell is either dropping support entirely for older than Windows 7 or LLVM adding the fail fast intrinsic, based on this comment.

Anyone know whether LLVM added that intrinsic yet, or if there is an issue somewhere for that?

@mati865
Copy link
Contributor

mati865 commented Jul 12, 2020

Anyone know whether LLVM added that intrinsic yet, or if there is an issue somewhere for that?

It's only implemented as Clang builtin, so no change for Rust.

@wesleywiser
Copy link
Member

The main blocker as far as I can tell is either dropping support entirely for older than Windows 7 or LLVM adding the fail fast intrinsic, based on this comment.

Since Windows 7 is now the minimum supported version of Windows, it looks like we can use the RaiseFailFastException function.

@rylev
Copy link
Member

rylev commented Mar 11, 2021

I believe we are using failfast everywhere we aborting. Here's what std::process:abort compiles to on my machine which according to the docs should cause a fast fail exception:

deleteme!std::process::abort:
00007ff7`c45973f0 50               push    rax
00007ff7`c45973f1 b907000000       mov     ecx, 7
00007ff7`c45973f6 cd29             int     29h
00007ff7`c45973f8 0f0b             ud2   

There is a call to ud2 after this, but I believe this instruction is never reached.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. O-windows Operating system: Windows T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants