i386 int3 handling, running vs stepping

Doug Evans
2009-02-01T23:18:35Z

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?
[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
(gdb)

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