Re: Stepping off breakpoints in non-stop debugging mode

[Jim Blandy <jimb at codesourcery dot com>]

Daniel Jacobowitz <drow at false.org> writes:
> 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?

You're right in your original assertion, that that code isn't
necessary where I had it.  I've taken it out.

As far as PTRACE_SINGLESTEP is concerned, isn't pushfl the only
user instruction that can observe the state of TF anyway?

Here's the test program I was using.  What am I seeing here?

  $ uname -a
  Linux pip 2.6.22.9-61.fc6 #1 SMP Thu Sep 27 18:48:03 EDT 2007 i686 i686 i386 GNU/Linux
  $ cat pushfl.c
  #include <stdio.h>

  int
  main (int argc, char **argv)
  {
    unsigned int flags;

    asm ("pushfl; popl %0" : "=r" (flags));

    printf ("0x%08x\n", flags);

    return 0;
  }
  $ ~/gdb/pub/nat/gdb/gdb pushfl
  GNU gdb 6.7.50.20071206-cvs
  Copyright (C) 2007 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "i686-pc-linux-gnu"...
  (gdb) start
  Breakpoint 1 at 0x8048390: file pushfl.c, line 5.
  Starting program: /home/jimb/gdb/ool/play/pushfl 
  main () at pushfl.c:5
  5       {
  (gdb) step
  main () at pushfl.c:8
  8         asm ("pushfl; popl %0" : "=r" (flags));
  (gdb) 
  5       {
  (gdb) 
  10        printf ("0x%08x\n", flags);
  (gdb) c
  Continuing.
  0x00000386

  Program exited normally.
  (gdb) start
  Breakpoint 2 at 0x8048390: file pushfl.c, line 5.
  Starting program: /home/jimb/gdb/ool/play/pushfl 
  main () at pushfl.c:5
  5       {
  (gdb) c
  Continuing.
  0x00000282

  Program exited normally.
  (gdb)