Re: Single-stepping through INT nn instructions

[Eli Zaretskii <eliz@gnu.org>]

> > > So you're trying to step *into* an int, not over it, right?
> >
> > I meant this: suppose the debuggee is stopped right in front of the
> > INT nn instruction.  Now I want to do a "stepi" in GDB.
> 
> Hmm.  The system call seems to happen on the instruction *after* the
> int, so I think I have no idea what's going on here.  I don't think
> GDB can really "simulate" an `int' in this context.  Let me know what
> you come up with.

I believe that what you see on Linux proves that `ptrace' somehow
handles this behind the scenes:

> (gdb)
> 0x804caa2 in __write ()
> 1: x/i $eip  0x804caa2 <__write+18>:    int    $0x80
> (gdb)
> 0x804caa4 in __write ()

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).

To see the problem, set a software watchpoint and then run the
debuggee through a line that calls printf: it will crash.

Jim, perhaps doing the above is not the same as repeated stepi, so
maybe you should try on Linux with software watchpoints, like I did.

I solved the problem in go32-nat.c by clearing TF and simulating it
with an INT 3 opcode inserted right after INT nn.  See the patches I
posted today.