Re: Single-stepping through INT nn instructions

[DJ Delorie <dj@delorie.com>]

> Here, single-step resumed right after the Int 80h call.  Doesn't this
> look like some kind of magic?
>  
> In the DJGPP version, it doesn't work so smoothly.  However, the
> problem seems to be that the Trap Flag is set when INT nn is hit.
> 
> DJ, is it correct that having TF set when INT nn is issued is a Bad
> Idea?  I tested this only with Int 31h, the DPMI interrupt, but I
> vaguely recall that it's a bad idea in general (e.g., __dpmi_int
> clears it).

INT is special in that the handler can (and usually *should*) modify
the flags register before returning, such that (unlike a hardware
interrupt) state is not preserved 100%.  If the INT handler resets the
trap flag, single stepping will be disabled upon return.

Whether or not TF is preserved across INT is up to the handler, not
the function that invokes the INT opcode.  Since we have no control
over the handlers (esp for DPMI), I think using an INT3 opcode is a
reasonable workaround.

On a side note, I've noticed that thw win32 API's single-stepping
stuff has a similar problem, so I have to check and re-set TF during
other exceptions.  MS will also automagically not allow you to
single-step into a call to a system DLL.