This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: i386 int3 handling, running vs stepping
- From: teawater <teawater at gmail dot com>
- To: Doug Evans <dje at google dot com>
- Cc: gdb at sourceware dot org
- Date: Mon, 2 Feb 2009 14:19:16 +0800
- Subject: Re: i386 int3 handling, running vs stepping
- References: <20090201231819.A9FB61C7A19@localhost>
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