lkml.org 
[lkml]   [2005]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectMore trouble with i386 EFLAGS and ptrace
    It looks like the changes to preserve eflags when single-stepping don't work
    right with signals. Take this test case:

    <snip>
    #include <signal.h>
    #include <unistd.h>

    volatile int done;

    void handler (int sig)
    {
    done = 1;
    }

    int main()
    {
    while (1)
    {
    done = 0;
    signal (SIGALRM, handler);
    alarm (1);
    while (!done);
    }
    }
    <snip>

    And this GDB session:

    (gdb) b 18
    Breakpoint 1 at 0x804840d: file test.c, line 18.
    (gdb) r
    Starting program: /home/drow/eflags/test

    Breakpoint 1, main () at test.c:18
    18 while (!done);
    (gdb) p/x $eflags
    $1 = 0x200217
    (gdb) c
    Continuing.

    Program received signal SIGTRAP, Trace/breakpoint trap.
    0x08048414 in main () at test.c:18
    18 while (!done);
    (gdb) p/x $eflags
    $2 = 0x200302

    There's an implied delay before the "c" which is long enough for the signal
    handler to become pending.

    The reason this happens is that when the inferior hits a breakpoint, the
    first thing GDB will do is remove the breakpoint, single-step past it, and
    reinsert it. So GDB does a PTRACE_SINGLESTEP, and the kernel invokes the
    signal handler (without single-step - good so far). When the signal handler
    returns, we've lost track of the fact that ptrace set the single-step flag,
    however. So the single-step completes and returns SIGTRAP to GDB. GDB is
    expecting a SIGTRAP and reinserts the breakpoint. Then it resumes the
    inferior, but now the trap flag is set in $eflags. So, oops, the continue
    acts like a step instead.

    What to do? We need to know when we restore the trap bit in sigreturn
    whether it was set by ptrace or by the application (possibly including by
    the signal handler).

    Andrew, serious kudos for GDB's sigstep.exp, which uncovered this problem
    (through a much more complicated test - I may add the smaller one).

    --
    Daniel Jacobowitz
    CodeSourcery, LLC
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:10    [W:0.029 / U:91.944 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site