Re: i386 int3 handling, running vs stepping

Mark Kettenis
2009-02-03T09:21:05Z

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