[RFA] Re: x86 linux GDB and SIGALRM
Mark Kettenis
kettenis@wins.uva.nl
Mon May 1 11:53:00 GMT 2000
[ There is a comment right before this code by JimB, so maybe you want
to comment on this Jim. ]
I think I've found the bug that's causing the problem Jonathan was
seeing. This patch restores the behaviour of GDB 4.18. GDB 4.18 was
released before handle_inferior_event() was introduced. At the point
of the check_sigtramp2() call there was a "goto check_sigtramp2".
Since in the old situation after the check_sigtramp2 code the
keep_going label would be reached, I think that the we should call
keep_going() here and return.
If we don't this we'll land in the breakpoint handling code. The
breakpoint handling code has the side-effect of cancelling any single
stepping and stopping right away. Now if we single step, but the
OS arranges to actually pass us a pending signal before actually
stepping (which is what happens on Linux/i386), we'll never step and
we see the behaviour that Jonathan observed.
[ Perhaps I should modify the comment a bit, now that the code
actually does keep_going. ]
Mark
2000-05-01 Mark Kettenis <kettenis@gnu.org>
* infrun.c (handle_inferior_event): Add missing call to keep_going
and missing return when handling an ordinary signal from the
inferior.
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.8
diff -u -p -r1.8 infrun.c
--- infrun.c 2000/04/20 11:00:34 1.8
+++ infrun.c 2000/05/01 18:43:13
@@ -2274,6 +2274,8 @@ handle_inferior_event (struct execution_
the HP-UX maintainer to furnish a fix that doesn't break other
platforms. --JimB, 20 May 1999 */
check_sigtramp2 (ecs);
+ keep_going (ecs);
+ return;
}
/* Handle cases caused by hitting a breakpoint. */
More information about the Gdb
mailing list