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
On Mon, Dec 10, 2007 at 03:05:01PM -0800, Jim Blandy wrote:
> If signal handler trampolines can use sysenter / syscall, then we'll
> need to recognize those, too. (Can they?)
Yes, I think so. It depends on the kernel version and the vDSO
variant it selected. Maybe not, though - there was some trouble about
getting the right registers saved.
> >> + /* 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.
>
> It does apply to GDB! You can write a statement that does "pushfl;
> popl %0" and behaves differently depending on whether you continue
> over it or step over it.
You're not supposed to be able to do that. The kernel goes to great
trouble to make sure that you can PTRACE_SINGLESTEP through such a
sequence and have the same thing happen that would if no debugger
was attached. My rule of thumb is that every time you have to
explicitly modify TF, you're clobbering the program's state. Am
I wrong?
See is_setting_trap_flag in the kernel. Of course, it leaves the
pushf case for debuggers to handle if they want to. Wine probably
does.
--
Daniel Jacobowitz
CodeSourcery