Skip to content

[X86] Preserve live SEH state at shared rewrite calls - #5

Merged
gmh5225 merged 2 commits into
mainfrom
codex/x86-seh-dynamic-parent-calls
Oct 15, 2026
Merged

gmh5225 merged 2 commits into
mainfrom
codex/x86-seh-dynamic-parent-calls

Conversation

@gmh5225

@gmh5225 gmh5225 commented Oct 15, 2026 •

Copy link
Copy Markdown

A PE32 SEH rewrite can reach one source call through different active scope states. The x86 state pass previously reset that call to the parent base state, and _setjmp3 captured the base state instead of the selected scope.

Add a checked, call-site-only llvm.rewrite.win-x86-seh-inherit-state contract for ordinary calls in rewrite-owned SEH parents. Calls retain the physical state selected by incoming scope boundaries, and the compiler-owned (buffer, 0) setjmp interface captures a volatile load of that state. State-store hoisting respects an inherited call before a later resetting call.

The x86 SEH runtime does not restore callee-saved registers on handler entry. Model this clobber at the EH pad for rewrite-owned SEH parents, including values used only on an exceptional path after a nonreturning call. Native Wine execution reproduced a stale logical frame address in EDI before this fix.

Validation rejects function-level markers, nonempty values, missing noinline, invokes, tail calls, intrinsics, inline assembly, funclet calls, unsupported parents and malformed capture interfaces. Target-specific validation lives in X86SEHStateCalls.cpp; the public capability macro allows NeverD to refuse this shape with older LLVM builds.

Validation: 52 LLVM RUN lines passed, covering O0/O2, optimized IR, SEH3/EH4 generation, handler-only register liveness, predecessor hoisting, malformed contracts and existing callback-state/source-state-order regressions. Both state-reset failures and the handler liveness failure were reproduced before their fixes. NeverD source replay and verifier-clean installation mutations pass for the two new runtime scenarios, with 40 Wine executions covering both patch modes, optimization settings and rebasing. LLVM 22 changed-line formatting and diff checks pass.

The complete NeverD qualification passed: 66 source scenarios and 1,320 Wine executions, followed by an independent 1,320-execution replay; 7,980 C++ tests passed with 51 explicit environment/external-fixture skips and zero failures; 108 Python registration checks and all 309 documentation files passed. The release admission policy passed all eight checks. The older artifact build was cancelled because it lacked the handler register fix. The final package will be built from main under the new r6 tag.

@github-actions

Copy link
Copy Markdown

Hello @gmh5225 👋

Thank you for submitting a Pull Request (PR) to the LLVM Project. Since this is your first PR, here are a few useful links covering our main contribution policies and review practices.

  • All contributions to LLVM must follow our LLVM AI Tool Use Policy. In particular, if you used AI while working on this PR, remember to add a note to the PR description.
  • The LLVM Code-Review Policy and Practices document contains practical information about the PR process, including how patches are reviewed and accepted, and who can review a PR.
  • Our LLVM Developer Policy describes our expectations for code quality, commit summaries and contains notes on our CI system.

Please reply to this message to confirm that you have read these policies, especially the LLVM AI Tool Use Policy, and that any AI tool usage has been noted in the PR description.


Frequently asked questions

How do I add reviewers?

This PR will be automatically labeled, and the relevant teams will be notified. For some parts of the project, reviewers may also be added automatically.

You can also add reviewers manually using the Reviewers section on this page. If you cannot use that section, it is probably because you do not have write permissions for the repository. In that case, you can request a review by tagging reviewers in a comment using @ followed by their GitHub username.

What if there are no comments?

If you have not received any comments on your PR after a week, you can request a review by pinging the PR with a comment such as “Ping”. The common courtesy ping rate is once a week. Please remember that you are asking for volunteer time from other developers.

Are any special GitHub settings required to contribute to LLVM?

We only require contributors to have a public email address associated with their GitHub commits, see this section of LLVM Developer Policy for details.


If you have questions, feel free to leave a comment on this PR, or ask on LLVM Discord or LLVM Discourse.

Thank you,
The LLVM Community

@gmh5225
gmh5225 marked this pull request as ready for review October 15, 2026 19:52
@gmh5225
gmh5225 merged commit 06788fb into main Oct 15, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants