Skip to content

Conversation

@VSadov
Copy link
Member

@VSadov VSadov commented Feb 25, 2022

More reliable fix for: #65292

Check dynamically for RtlRestoreContext on x86 and if available (i.e. on Win11), use the same codepath as on x64.
Otherwise fallback to preexisting mechanism where a context is patched in an exception filter.

@ghost ghost assigned VSadov Feb 25, 2022
@ghost ghost added the area-VM-coreclr label Feb 25, 2022
Copy link
Member

Choose a reason for hiding this comment

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

You should not need __stdcall here

@VSadov
Copy link
Member Author

VSadov commented Feb 25, 2022

@tommcdon @hoyosjs - this change may indirectly affect ThreadAbort scenario on Win11/x86.
In some cases it will start using the same code as on x64, so it is not something entirely new, but it is a change. I do not think we have a lot of coverage for thread abort scenario here.

Is this something that may need extra testing on the debugger side?

@VSadov VSadov marked this pull request as ready for review February 25, 2022 23:54
@VSadov
Copy link
Member Author

VSadov commented Mar 1, 2022

I have run the diagnostics tests with this change a few times (on Windows11 with x86 configuration). I did not notice any differences from the baseline run without changes.

I think we can assume the change does not break/regress anything in the debugger scenarios.

@VSadov VSadov requested review from jkotas and mangod9 March 1, 2022 22:44
@VSadov
Copy link
Member Author

VSadov commented Mar 1, 2022

rebased onto recent main to force stuck tests to run.

RaiseException(EXCEPTION_HIJACK, 0, 0, NULL);
if (!pfnRtlRestoreContext)
{
RestoreContextSimulated(pThread, pCtx, &frame);
Copy link
Member

Choose a reason for hiding this comment

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

Do we have a problem on this path with preserving last error?

Copy link
Member Author

Choose a reason for hiding this comment

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

It looks like we did not try to restore last error on x86 even before this change.
I am actually not sure when the last error could be lost, assuming nothing fails.

I can move the last error restore to the point right after the GCX_PREEMP/GCX_PREEMP_END, but do we need that at all?

Copy link
Member

Choose a reason for hiding this comment

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

For example, I think STRESS_LOG1 may modify the last error in some cases.

I think it would be best to restore the last error right before returning EXCEPTION_CONTINUE_EXECUTION in the filter.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah. It is not too hard to restore right before it continues.

Copy link
Member Author

Choose a reason for hiding this comment

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

Also the docs on GetLastError say "some functions set the last-error code to 0 on success and others do not."

Comment on lines 2717 to 2719
else
#endif // TARGET_X86
{
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
else
#endif // TARGET_X86
{
#endif // TARGET_X86

Nit: I would unindent the rest to make this easier to follow

Copy link
Member Author

Choose a reason for hiding this comment

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

Right. Since it is unreachable.

Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

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

LGTM otherwise. Thanks!

@VSadov
Copy link
Member Author

VSadov commented Mar 2, 2022

Thanks!!

@VSadov VSadov merged commit defd20c into dotnet:main Mar 2, 2022
@VSadov VSadov deleted the x86ctx branch March 2, 2022 04:22
@tommcdon
Copy link
Member

tommcdon commented Mar 2, 2022

@tommcdon @hoyosjs - this change may indirectly affect ThreadAbort scenario on Win11/x86. In some cases it will start using the same code as on x64, so it is not something entirely new, but it is a change. I do not think we have a lot of coverage for thread abort scenario here.

Is this something that may need extra testing on the debugger side?

Thanks for letting us know @VSadov! We will pay special attention to Debugger::FuncEvalAbort scenarios.

VSadov added a commit to VSadov/runtime that referenced this pull request Mar 2, 2022
…net#65878)

* RestoreContextSimulated

* probe for RtlRestoreContext

* ntdll.dll

* restore self-trap sequence

* PR feedback

* Clarify CopyContext in RedirectedHandledJITCaseExceptionFilter

* simpler indentation.

* restore last error on the legacy path.

* Update src/coreclr/vm/threads.h

Co-authored-by: Dan Moseley <[email protected]>
agocke pushed a commit to agocke/runtime that referenced this pull request Mar 8, 2022
…net#65878)

* RestoreContextSimulated

* probe for RtlRestoreContext

* ntdll.dll

* restore self-trap sequence

* PR feedback

* Clarify CopyContext in RedirectedHandledJITCaseExceptionFilter

* simpler indentation.

* restore last error on the legacy path.

* Update src/coreclr/vm/threads.h

Co-authored-by: Dan Moseley <[email protected]>
carlossanlop pushed a commit that referenced this pull request Mar 8, 2022
…#66120)

* Use CopyContext to restore saved context on X86 (#65490)

* Use CopyContext to restore saved context on X86

* PR feedback

* more PR feedback

* Do not copy XState other than AVX when redirecting for GC stress (#65825)

* Do not copy XState other than AVX

* #if defined(TARGET_X86) || defined(TARGET_AMD64)

* mask XState unconditionally

* Ensure XSTATE_MASK_AVX is set before calling EEGetThreadContext

* redundant supportsAVX, more clear comment

* PR feedback

* null-check the redirect context before using. (#65910)

* null-check the redirect context before using.

* tweak the comment

* do not allocate context if InitializeContext has unexpected results.

* EE Suspension on x86 should use RtlRestoreContext when available (#65878)

* RestoreContextSimulated

* probe for RtlRestoreContext

* ntdll.dll

* restore self-trap sequence

* PR feedback

* Clarify CopyContext in RedirectedHandledJITCaseExceptionFilter

* simpler indentation.

* restore last error on the legacy path.

* Update src/coreclr/vm/threads.h

Co-authored-by: Dan Moseley <[email protected]>

Co-authored-by: Dan Moseley <[email protected]>
carlossanlop pushed a commit that referenced this pull request Mar 15, 2022
* Use CopyContext to restore saved context on X86 (#65490)

* Use CopyContext to restore saved context on X86

* PR feedback

* more PR feedback

* Do not copy XState other than AVX when redirecting for GC stress (#65825)

* Do not copy XState other than AVX

* #if defined(TARGET_X86) || defined(TARGET_AMD64)

* mask XState unconditionally

* Ensure XSTATE_MASK_AVX is set before calling EEGetThreadContext

* redundant supportsAVX, more clear comment

* PR feedback

* null-check the redirect context before using. (#65910)

* null-check the redirect context before using.

* tweak the comment

* do not allocate context if InitializeContext has unexpected results.

* EE Suspension on x86 should use RtlRestoreContext when available (#65878)

* RestoreContextSimulated

* probe for RtlRestoreContext

* ntdll.dll

* restore self-trap sequence

* PR feedback

* Clarify CopyContext in RedirectedHandledJITCaseExceptionFilter

* simpler indentation.

* restore last error on the legacy path.

* Update src/coreclr/vm/threads.h

Co-authored-by: Dan Moseley <[email protected]>

Co-authored-by: Vladimir Sadov <[email protected]>
Co-authored-by: Dan Moseley <[email protected]>
@ghost ghost locked as resolved and limited conversation to collaborators Apr 2, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants