i386 int3 handling, running vs stepping

Doug Evans dje@google.com
Sun Feb 1 23:18:00 GMT 2009

gdb is inconsistent in its handling of int3 instructions on x86.

bash$ cat int3.S
	.global main

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?
[whether that's achieved with decr_pc_after_break or whatever
is a separate question]
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

Note that int3 was stepping over without a SIGTRAP being generated.

[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.]

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

More information about the Gdb mailing list