This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: i386 int3 handling, running vs stepping
- From: Daniel Jacobowitz <drow at false dot org>
- To: Doug Evans <dje at google dot com>
- Cc: gdb at sourceware dot org
- Date: Sun, 1 Feb 2009 18:32:51 -0500
- Subject: Re: i386 int3 handling, running vs stepping
- References: <20090201231819.A9FB61C7A19@localhost>
On Sun, Feb 01, 2009 at 03:18:19PM -0800, Doug Evans wrote:
> 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.
I think it's right the way it is, and I know people take advantage of
this for hardwired breakpoints.
> 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 can't see a plausible way around this, can you? The SIGTRAP is
identical to the one for PTRACE_SINGLESTEP - unless the kernel
annotates the siginfo differently?
--
Daniel Jacobowitz
CodeSourcery