Re: i386 int3 handling, running vs stepping

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Sun,  1 Feb 2009 15:18:19 -0800 (PST)
> From: dje@google.com (Doug Evans)
> 
> gdb is inconsistent in its handling of int3 instructions on x86.
> 
> bash$ cat int3.S
> 	.text
> 	.global main
> main:
> 	nop
> 	int3
> 	nop
> 	hlt
> 
> bash$ gcc -g -Wa,-g int3.S -o int3
> bash$ gdb int3
> (gdb) run
> -->
> Program received signal SIGTRAP, Trace/breakpoint trap.
> main () at int3.S:6
> 6		nop
> 
> Note that $pc is the insn AFTER the int3.
> Question: Is this a bug?  Should $pc point to the int3 instead?

No, this is not a bug.  It is how the architecture works.

> I can argue either case, I don't have a preference per se.
> 
> Trying things again, this time stepi'ing over the insn:
> 
> bash$ gdb int3
> (gdb) start
> [...]
> Temporary breakpoint 1, main () at int3.S:4
> 4		nop
> Current language:  auto; currently asm
> (gdb) si
> 5		int3
> (gdb) si
> 6		nop
> (gdb) 
> 
> Note that int3 was stepping over without a SIGTRAP being generated.

Yes, the SIGTRAP is eaten by gdb because it was an expected
side-effect of single-stepping the instruction.  The ptrace(2)/wait(2)
interface traditionally used by debuggers can't really tell the
difference between hitting a breakpoint and single-stepping.  This
could be overcome with some kernel hacking by making it possible to
look at the signal code (probably already possible on recent Linux
kernels).  But I don't see a real reason to do that.

> [I haven't tried setting a breakpoint at the int3 insn, but
> GDB can know whether it's stepping over one of its own breakpoints
> or an int3 that's part of the program, so I think(!) gdb can be consistent
> here regardless.]

GDB will interpret this as a normal breakpoint, and won't generate a SIGTRAP.

> The only question I have is what should the value of $pc be after
> hitting an int3 instruction during normal execution? (ie. no stepping,
> no breakpoints).

The address of the instruction immediately following the int3 instruction.