i386 int3 handling, running vs stepping

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