Re: i386 int3 handling, running vs stepping

teawater
2009-02-02T06:19:25Z

Hi Doug,

On Mon, Feb 2, 2009 at 07:18, Doug Evans <dje@google.com> wrote:
> 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.
>

This is not a bug.
This because when x86 stop by breakpoint, the pc of it will point to
next instruction. If this breakpoint is set by gdb, gdb will use
adjust_pc_after_break set it to break address.
Because this is not a gdb breakpoint, it stop at this address.

And inferior stop at there because gdb think this is a random signal.
If you set debug infrun 1, it will clear:
infrun: stop_pc = 0x8048346
infrun: random signal 5

Program received signal SIGTRAP, Trace/breakpoint trap.
infrun: stop_stepping

> 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 think this is because si return SIGTRAP too, gdb doesn't know there
a random signal.

Thanks,
Hui