Re: i386 int3 handling, running vs stepping

[teawater <teawater@gmail.com>]

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