This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Stepping off breakpoints in non-stop debugging mode
- From: Daniel Jacobowitz <drow at false dot org>
- To: gdb at sourceware dot org
- Date: Sat, 8 Dec 2007 12:03:59 -0500
- Subject: Re: Stepping off breakpoints in non-stop debugging mode
- References: <m33audczfp.fsf@codesourcery.com>
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