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.

Sign up for GitHub

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

Adjust IP after an AV during an STEP with FEATURE_EMULATE_SINGLESTEP enabled #105633

Merged
merged 4 commits into from
Jul 31, 2024
Merged

Adjust IP after an AV during an STEP with FEATURE_EMULATE_SINGLESTEP enabled #105633

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d6f6d7f
Trying to fix step in a line that will throw an AV
thaystg Jul 29, 2024
233ea19
Fix build
thaystg Jul 29, 2024
91e4b78
Addressing Noah's comments.
Jul 30, 2024
1dfd383
Removing changes not needed anymore.
thaystg Jul 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion src/coreclr/debug/ee/controller.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3232,7 +3232,7 @@ void DebuggerController::UnapplyTraceFlag(Thread *thread)
// so there should be nothing to do. However, we still assert b/c we want to know how
// we'd actually hit this.
// @todo - is there a path if TriggerUnwind() calls DisableAll(). But why would
CONSISTENCY_CHECK_MSGF(false, ("How did we get here?. thread=%p\n", thread));
//CONSISTENCY_CHECK_MSGF(false, ("How did we get here?. thread=%p\n", thread)); it can be caused in a scenario where we are stepping and an AV is thrown
LOG((LF_CORDB,LL_INFO1000, "DC::UnapplyTraceFlag couldn't get context.\n"));
return;
}
Expand Down
11 changes: 11 additions & 0 deletions src/coreclr/vm/exceptionhandling.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5426,6 +5426,17 @@ BOOL IsSafeToCallExecutionManager()

BOOL IsSafeToHandleHardwareException(PCONTEXT contextRecord, PEXCEPTION_RECORD exceptionRecord)
{
#ifdef FEATURE_EMULATE_SINGLESTEP
Thread *pThread = GetThreadNULLOk();
if (pThread && pThread->IsSingleStepEnabled() &&
Copy link
Member

Choose a reason for hiding this comment

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

Any reason why we only invoke pThread->HandleSingleStep() in some cases and not others? Could we do something like this in IsSafeToHandleHardwareException() and remove the HandleSingleStep call from HandleHardwareException?

#ifdef FEATURE_EMULATE_SINGLESTEP
Thread *pThread = GetThreadNULLOk();
if (pThread != NULL && g_pDebugInterface != NULL)
{
    HandleSingleStep(contextRecord, exceptionRecord, pThread);
}
#endif

It feels easier to understand if we always invoke it from one place rather than conditionally invoke it from two different place.

exceptionRecord->ExceptionCode != STATUS_BREAKPOINT &&
exceptionRecord->ExceptionCode != STATUS_SINGLE_STEP &&
exceptionRecord->ExceptionCode != STATUS_STACK_OVERFLOW)
{
pThread->HandleSingleStep(contextRecord, exceptionRecord->ExceptionCode);
Copy link
Member

Choose a reason for hiding this comment

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

The updated version of the change looks like it still calls HandleSingleStep from two different places, once here and once over in HandleHardwareException.

I was suggesting that we converge those into a single call here. Is there a reason we need two different calls? If yes it would be great to add a comment saying why we have both, and if not it would be nice to get rid of the HandleHardwareException portion and do it all here.

}
#endif

PCODE controlPc = GetIP(contextRecord);

if (IsIPInWriteBarrierCodeCopy(controlPc))
Expand Down
Loading