topic Single stepping on branches, exception or interrupts. in Software Tuning, Performance Optimization & Platform Monitoring

Single stepping on branches, exception or interrupts.

Stott__Graham — Sat, 11 Feb 2012 07:56:09 GMT

I hope someone can help with the following questions or point me at a document that explains how this works. I hope I am just missing something obvious. I haveread at all the SDMs (Vols 3a and 3b) without getting insight.

If I set the TR flag in the rflags register and also set the BTF flags in the MSR_DEBUGCTL MSR, then the processor will generate a "single step" debug exception the next time it takes a branch, services an interrupt or generates an exception. I am assuming that I have set the processor to only do this at ring level 3.

1: When is the interrupt or exception delivered to the actual interrupt or exception handler? As the debug exception has a higher priority then the other exceptions or interrupt, the processor will vector to the #DB (interrupt 1) IDT entry. When does it vector to the other exception or interrupt IDT entry? On the next iret? Or does the code after handling the debug exception have to jump to the correct handler (see next question).

2: In the #DB handler is there anyway to tell the reason for entering the debug handler. In other words can the handler code tell that it was a branch, exception or interrupt that cause the entry into the #DB handler. Note that it is possible that both a branch and an interrupt or exception can occur at the same time.

Thanks

Single stepping on branches, exception or interrupts.

SergeyKostrov — Mon, 13 Feb 2012 00:22:10 GMT

Quoting stott1

...
2: In the #DB handler is there anyway to tell the reason for entering the debug handler. In other words can the handler code tell that it was a branch, exception or interrupt that cause the entry into the #DB handler. Note that it is possible that both a branch and an interrupt or exception can occur at the same time.
Thanks

Here a couple of places I would look at:

- Microsoft Platform SDK ( any version ). Look at '..\Samples\WinBase\Debug\' folder with examples
related to Debugging on Windows platforms;

- On MSDN "Debugging and Error Handling" topic;

- Win32 API structure 'EXCEPTION_DEBUG_INFO' has 'EXCEPTION_RECORD' member (structure )and
it is filled with information about an exception.

Best regards,
Sergey

Single stepping on branches, exception or interrupts.

gladiolus — Mon, 13 Feb 2012 10:38:04 GMT

First 32 interrupts (00h-1Fh) are reserved for exceptions. Exceptions behave very similarly to interrupts - every exception forces interrupting the program execution and control is transfered from the currently-executing program to the routine handling the interrupting exception. These routines are part of OS kernel and they are called "exception handlers". During the control transfer to the exception handler, the CPU stops execution of the program and saves its return instruction pointer (RIP), stack pointer (RSP), flags register (RFLAGS). The handler is responsible for saving the remaining state of the interrupted program (GPR, XMM, ). Saving registers allows the CPU to restart the interrupted program after the handler finishes exception handling.

Single stepping on branches, exception or interrupts.

Patrick_F_Intel1 — Mon, 13 Feb 2012 13:38:26 GMT

Hello Stot1,
These questions are out of my range of knowledge.
I've sent them off to some other folks but I don't know if they will have theknowledge or timeto respond.
What are trying to accomplish? Perhaps there are others ways of reaching your goals.
Have you looked at how GDB does single-instruction mode?
I assumegdb must do this.
Pat

Single stepping on branches, exception or interrupts.

Stott__Graham — Tue, 14 Feb 2012 07:51:35 GMT

First of all, thanks for all the replies.

I think I have mostly worked out the answer to my first question.

The description in the SDM on Single-stepping on Branches, Exception and Interrupts talks about exceptions when it fact they are going to be faults. Faults occur before the instruction is executed. So after the debug trap has occurred and the handler does a iret to go back to the code being "stepped", it goes back to the same instruction. In this case, the rflags that were loaded by the iret will have the RF bit on. This will cause the hardware to not generate the debug fault again but will take the actual exception (fault). Note that the description of the stepping facility does not discuss this at all. For interrupts, the interrupt is held pending until interrupts are un-masked.

The SDM also has a typo in that it says "The debugger must reset the BTF and TF flags before resuming ...". In fact it should be ".. set the BTF and TF ... ".

Hopefully I can aslo work out the ansered to my second question.

Thanks again.

Stott1