i386 int3 handling, running vs stepping

i386 int3 handling, running vs stepping

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

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

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

Re: i386 int3 handling, running vs stepping

[Daniel Jacobowitz]

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

Re: i386 int3 handling, running vs stepping

[Doug Evans]

On Sun, Feb 1, 2009 at 3:32 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Sun, Feb 01, 2009 at 03:18:19PM -0800, Doug Evans wrote:
>
>> 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?

I haven't looked into siginfo, but can gdb look at the insn?  [akin to
displaced stepping handling]

Re: i386 int3 handling, running vs stepping

[Doug Evans]

On Sun, Feb 1, 2009 at 3:32 PM, Daniel Jacobowitz <drow@false.org> wrote:
> 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.
>

btw, i386-tdep.c:i386_displaced_step_fixup has this:

          /* If we have stepped over a breakpoint, set the %eip to
             point at the breakpoint instruction itself.

             (gdbarch_decr_pc_after_break was never something the core
             of GDB should have been concerned with; arch-specific
             code should be making PC values consistent before
             presenting them to GDB.)  */
          if (i386_breakpoint_p (insn))
            {
              if (debug_displaced)
                fprintf_unfiltered (gdb_stdlog,
                                    "displaced: stepped breakpoint\n");
              eip--;
            }

Given that the pc should be left AFTER the int3 when stepping over it,
do we want to delete this code?

Re: i386 int3 handling, running vs stepping

[Daniel Jacobowitz]

On Sun, Feb 01, 2009 at 03:38:04PM -0800, Doug Evans wrote:
> I haven't looked into siginfo, but can gdb look at the insn?  [akin to
> displaced stepping handling]

I suppose, but I don't really see a point.

-- 
Daniel Jacobowitz
CodeSourcery

Re: i386 int3 handling, running vs stepping

[Robert Dewar]

Daniel Jacobowitz wrote:

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

same trap, but surely gdb has enough info to figure out the
difference?

Re: i386 int3 handling, running vs stepping

[teawater]

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

Re: i386 int3 handling, running vs stepping

[Doug Evans]

On Sun, Feb 1, 2009 at 8:24 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Sun, Feb 01, 2009 at 03:38:04PM -0800, Doug Evans wrote:
>> I haven't looked into siginfo, but can gdb look at the insn?  [akin to
>> displaced stepping handling]
>
> I suppose, but I don't really see a point.

Apologies, it's not clear what point you're referring to.

I guess the issue is whether int3's in programs are supported by gdb,
and by supported I mean users can rely on gdb flagging a SIGTRAP when
they're executed.  As you say, there are people who take advantage of
this for hardwired breakpoints.

There are various situations where gdb itself will singlestep code
(e.g., "step", "next", s/w watchpoints).  Can users expect to see the
SIGTRAP in these situations (and all others)?  And if the program is
being run by a script, can the script expect to see the SIGTRAP in all
cases?

Re: i386 int3 handling, running vs stepping

[Daniel Jacobowitz]

On Mon, Feb 02, 2009 at 12:03:13PM -0800, Doug Evans wrote:
> On Sun, Feb 1, 2009 at 8:24 PM, Daniel Jacobowitz <drow@false.org> wrote:
> > On Sun, Feb 01, 2009 at 03:38:04PM -0800, Doug Evans wrote:
> >> I haven't looked into siginfo, but can gdb look at the insn?  [akin to
> >> displaced stepping handling]
> >
> > I suppose, but I don't really see a point.
> 
> Apologies, it's not clear what point you're referring to.
> 
> I guess the issue is whether int3's in programs are supported by gdb,
> and by supported I mean users can rely on gdb flagging a SIGTRAP when
> they're executed.  As you say, there are people who take advantage of
> this for hardwired breakpoints.

Since it works today, and we know that people use it, I think we have
no choice but to consider it supported.

> There are various situations where gdb itself will singlestep code
> (e.g., "step", "next", s/w watchpoints).  Can users expect to see the
> SIGTRAP in these situations (and all others)?  And if the program is
> being run by a script, can the script expect to see the SIGTRAP in all
> cases?

That's certainly not the case today.  If you want to make it work, and
add a couple of tests for it, I've no objection - it seems a plausible
thing to do.  But I would prefer that any solution did not involve
reading the instruction at every step; that's quite slow, on a target
where we otherwise do not need to.

-- 
Daniel Jacobowitz
CodeSourcery

Re: i386 int3 handling, running vs stepping

[Doug Evans]

On Mon, Feb 2, 2009 at 1:49 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Mon, Feb 02, 2009 at 12:03:13PM -0800, Doug Evans wrote:
>> On Sun, Feb 1, 2009 at 8:24 PM, Daniel Jacobowitz <drow@false.org> wrote:
>> > On Sun, Feb 01, 2009 at 03:38:04PM -0800, Doug Evans wrote:
>> >> I haven't looked into siginfo, but can gdb look at the insn?  [akin to
>> >> displaced stepping handling]
>> >
>> > I suppose, but I don't really see a point.
>>
>> Apologies, it's not clear what point you're referring to.
>>
>> I guess the issue is whether int3's in programs are supported by gdb,
>> and by supported I mean users can rely on gdb flagging a SIGTRAP when
>> they're executed.  As you say, there are people who take advantage of
>> this for hardwired breakpoints.
>
> Since it works today, and we know that people use it, I think we have
> no choice but to consider it supported.
>
>> There are various situations where gdb itself will singlestep code
>> (e.g., "step", "next", s/w watchpoints).  Can users expect to see the
>> SIGTRAP in these situations (and all others)?  And if the program is
>> being run by a script, can the script expect to see the SIGTRAP in all
>> cases?
>
> That's certainly not the case today.  If you want to make it work, and
> add a couple of tests for it, I've no objection - it seems a plausible
> thing to do.  But I would prefer that any solution did not involve
> reading the instruction at every step; that's quite slow, on a target
> where we otherwise do not need to.

Thanks.
I don't know when I'd have time to get to this, mostly I wanted to
make sure I understood why things are the way they are.

For reference sake, while looking into something else I was reminded
that the x86 linux port already looks at the insn being stepped.  Heh.
 :-)
[Without suggesting it's now a-priori ok to and add such reads to all ports.]
[Things like trust-readonly can speed this up too.]

static void
i386_linux_resume (ptid_t ptid, int step, enum target_signal signal)
{
  int pid = PIDGET (ptid);

  int request = PTRACE_CONT;

  if (step)
    {
      struct regcache *regcache = get_thread_regcache (pid_to_ptid (pid));
      ULONGEST pc;
      gdb_byte buf[LINUX_SYSCALL_LEN];

      request = PTRACE_SINGLESTEP;

      regcache_cooked_read_unsigned
        (regcache, gdbarch_pc_regnum (get_regcache_arch (regcache)), &pc);

      /* Returning from a signal trampoline is done by calling a
         special system call (sigreturn or rt_sigreturn, see
         i386-linux-tdep.c for more information).  This system call
         restores the registers that were saved when the signal was
         raised, including %eflags.  That means that single-stepping
         won't work.  Instead, we'll have to modify the signal context
         that's about to be restored, and set the trace flag there.  */

      /* First check if PC is at a system call.  */
      if (target_read_memory (pc, buf, LINUX_SYSCALL_LEN) == 0
          && memcmp (buf, linux_syscall, LINUX_SYSCALL_LEN) == 0)
        {
          ULONGEST syscall;
          regcache_cooked_read_unsigned (regcache,
                                         LINUX_SYSCALL_REGNUM, &syscall);

          /* Then check the system call number.  */
          if (syscall == SYS_sigreturn || syscall == SYS_rt_sigreturn)
            {
              ULONGEST sp, addr;
              unsigned long int eflags;

              regcache_cooked_read_unsigned (regcache, I386_ESP_REGNUM, &sp);
              if (syscall == SYS_rt_sigreturn)
                addr = read_memory_integer (sp + 8, 4) + 20;
              else
                addr = sp;

              /* Set the trace flag in the context that's about to be
                 restored.  */
              addr += LINUX_SIGCONTEXT_EFLAGS_OFFSET;
              read_memory (addr, (gdb_byte *) &eflags, 4);
              eflags |= 0x0100;
              write_memory (addr, (gdb_byte *) &eflags, 4);
            }
        }
    }

  if (ptrace (request, pid, 0, target_signal_to_host (signal)) == -1)
    perror_with_name (("ptrace"));
}

Re: i386 int3 handling, running vs stepping

[Daniel Jacobowitz]

On Mon, Feb 02, 2009 at 05:26:29PM -0800, Doug Evans wrote:
> For reference sake, while looking into something else I was reminded
> that the x86 linux port already looks at the insn being stepped.  Heh.
>  :-)

Oh, yeah.  That's a shame :-(  IIRC this works without the fudging on
some kernels.

-- 
Daniel Jacobowitz
CodeSourcery

Re: i386 int3 handling, running vs stepping

[Mark Kettenis]

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

Re: i386 int3 handling, running vs stepping

[Mark Kettenis]

> Date: Mon, 2 Feb 2009 16:49:15 -0500
> From: Daniel Jacobowitz <drow@false.org>
>
> > I guess the issue is whether int3's in programs are supported by gdb,
> > and by supported I mean users can rely on gdb flagging a SIGTRAP when
> > they're executed.  As you say, there are people who take advantage of
> > this for hardwired breakpoints.
> 
> Since it works today, and we know that people use it, I think we have
> no choice but to consider it supported.
> 
> > There are various situations where gdb itself will singlestep code
> > (e.g., "step", "next", s/w watchpoints).  Can users expect to see the
> > SIGTRAP in these situations (and all others)?  And if the program is
> > being run by a script, can the script expect to see the SIGTRAP in all
> > cases?
> 
> That's certainly not the case today.  If you want to make it work, and
> add a couple of tests for it, I've no objection - it seems a plausible
> thing to do.  But I would prefer that any solution did not involve
> reading the instruction at every step; that's quite slow, on a target
> where we otherwise do not need to.

I don't really see any reason to change things here.