Re: Stepping off breakpoints in non-stop debugging mode

[Daniel Jacobowitz <drow@false.org>]

On Sat, Dec 08, 2007 at 01:23:38AM -0800, Jim Blandy wrote:
> - The current implementation of gdbarch_displaced_step_location is
>   pretty questionable, but I'm not sure where else would be better.

Ditto.  This may do.

> - It seems that it is never necessary to have more than one thread
>   doing displaced stepping at a time --- or else the assert in
>   displaced_step_prepare would trigger --- but I don't see why this
>   should be so.

Isn't this because you haven't been testing combined with Vladimir's
leave-breakpoints-inserted code?  resume is still going to force only
the current thread to resume and wait, so the single step will finish
before anything else gets a chance to hit a new breakpoint.  Combine
those two patches, this will start happening.  Add non-stop debugging
and it will happen even more.

> +static int
> +i386_syscall_p (gdb_byte *insn, ULONGEST *lengthp)
> +{
> +  if (insn[0] == 0xcd)
> +    {
> +      *lengthp = 2;
> +      return 1;
> +    }
> +
> +  return 0;
> +}

That's int, I assume.  May need sysenter / syscall, depending on the
platform.

> +  /* The list of issues to contend with here is taken from
> +     resume_execution in arch/i386/kernel/kprobes.c, Linux 2.6.20.
> +     Yay for Free Software!  */
> +
> +  /* Clear the TF flag in EFLAGS, which will always be set.  */
> +  {
> +    ULONGEST eflags;
> +    regcache_cooked_read_unsigned (regs, I386_EFLAGS_REGNUM, &eflags);
> +    eflags &= ~I386_TF_MASK;
> +    regcache_cooked_write_unsigned (regs, I386_EFLAGS_REGNUM, eflags);
> +  }

Does this manual adjustment of TF apply to GDB?  The kernel is
supposed to handle TF entirely inside ptrace, and expose the original
%eflags to GDB (though various kernel versions have gotten this wrong,
I believe it is right at last).  So if TF is set here, that means the
program being debugged had TF set already.

> +  /* Relocate the %eip, if necessary.  */
> +
> +  /* In the case of absolute or indirect jump or call instructions, or
> +     a return instruction, the new %eip needs no relocation.  */
> +  if (i386_absolute_jmp_p (insn)
> +      || i386_absolute_call_p (insn)
> +      || i386_ret_p (insn))
> +    ;
> +
> +  /* Except in the case of absolute or indirect jump or call
> +     instructions, or a return instruction, the new eip is relative to
> +     the displaced instruction; make it relative.  Well, signal
> +     handler returns don't need relocation either, but we use the
> +     value of %eip to recognize those; see below.  */
> +  if (! i386_absolute_jmp_p (insn)
> +      && ! i386_absolute_call_p (insn)
> +      && ! i386_ret_p (insn))

These two if statements look quite strange together.

-- 
Daniel Jacobowitz
CodeSourcery