[lkml]   [2005]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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:

#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);

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

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:10    [W:0.084 / U:0.924 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site