[NTOS/KDBK]

Fix the value for EIP used by KDBG after an INT3 set by KDBG itself. The address is already fixed by KiDispatchException, but only in the context frame, not in the trap frame and KDBG insists to use the trap frame for a lot of things. Also, after a cont from such an int3, KDBG uses a single step to re-enable the breakpoint (it needs to disable it after it was hit to be able to execute the actual instruction), but it used to dismiss *any* single steps after that. So make sure, that an actual single step, as created by the debugger is not being dismissed, but the break point is still restored after the next single step entry. You might expect that a kernel debugger would at least support setting breakpoints, but this is KDBG.

svn path=/trunk/; revision=70416
This commit is contained in:
Timo Kreuzer 2015-12-23 22:38:46 +00:00
parent 98a34bceb7
commit 385bbababc

View file

@ -38,6 +38,7 @@ static PKDB_BREAKPOINT KdbSwBreakPoints[KDB_MAXIMUM_SW_BREAKPOINT_COUNT]; /* Ena
static PKDB_BREAKPOINT KdbHwBreakPoints[KDB_MAXIMUM_HW_BREAKPOINT_COUNT]; /* Enabled hardware breakpoints, orderless */
static PKDB_BREAKPOINT KdbBreakPointToReenable = NULL; /* Set to a breakpoint struct when single stepping after
a software breakpoint was hit, to reenable it */
static BOOLEAN KdbpEvenThoughWeHaveABreakPointToReenableWeAlsoHaveARealSingleStep;
LONG KdbLastBreakPointNr = -1; /* Index of the breakpoint which cause KDB to be entered */
ULONG KdbNumSingleSteps = 0; /* How many single steps to do */
BOOLEAN KdbSingleStepOver = FALSE; /* Whether to step over calls/reps. */
@ -1407,6 +1408,15 @@ KdbEnterDebuggerException(
KdbpPrint("Couldn't restore original instruction after INT3! Cannot continue execution.\n");
KeBugCheck(0); // FIXME: Proper bugcode!
}
/* Also since we are past the int3 now, decrement EIP in the
TrapFrame. This is only needed because KDBG insists on working
with the TrapFrame instead of with the Context, as it is supposed
to do. The context has already EIP point to the int3, since
KiDispatchException accounts for that. Whatever we do here with
the TrapFrame does not matter anyway, since KiDispatchException
will overwrite it with the values from the Context! */
TrapFrame->Eip--;
}
if ((BreakPoint->Type == KdbBreakPointHardware) &&
@ -1428,8 +1438,6 @@ KdbEnterDebuggerException(
/* Delete the temporary breakpoint which was used to step over or into the instruction. */
KdbpDeleteBreakPoint(-1, BreakPoint);
TrapFrame->Eip--;
if (--KdbNumSingleSteps > 0)
{
if ((KdbSingleStepOver && !KdbpStepOverInstruction(TrapFrame->Eip)) ||
@ -1520,9 +1528,15 @@ KdbEnterDebuggerException(
if (KdbNumSingleSteps == 0)
Context->EFlags &= ~EFLAGS_TF;
goto continue_execution; /* return */
if (!KdbpEvenThoughWeHaveABreakPointToReenableWeAlsoHaveARealSingleStep)
{
goto continue_execution; /* return */
}
}
/* Quoth the raven, 'Nevermore!' */
KdbpEvenThoughWeHaveABreakPointToReenableWeAlsoHaveARealSingleStep = FALSE;
/* Check if we expect a single step */
if ((TrapFrame->Dr6 & 0xf) == 0 && KdbNumSingleSteps > 0)
{
@ -1645,6 +1659,9 @@ KdbEnterDebuggerException(
/* Check if we should single step */
if (KdbNumSingleSteps > 0)
{
/* Variable explains itself! */
KdbpEvenThoughWeHaveABreakPointToReenableWeAlsoHaveARealSingleStep = TRUE;
if ((KdbSingleStepOver && KdbpStepOverInstruction(KdbCurrentTrapFrame->Tf.Eip)) ||
(!KdbSingleStepOver && KdbpStepIntoInstruction(KdbCurrentTrapFrame->Tf.Eip)))
{