From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: gdb-patches@sourceware.org
Subject: [rfc][2/2] Signal delivery + software single-step is broken
Date: Wed, 19 Jan 2011 17:12:00 -0000 [thread overview]
Message-ID: <201101191642.p0JGgntq023362@d06av02.portsmouth.uk.ibm.com> (raw)
Hello,
even with the previous patch, some sigstep.exp tests are still failing.
This is due to a peculiarity of the linux-nat target, which sometimes
decides to *not* report a signal event to GDB's main event loop, but
simply re-dispatch the inferior directly.
This is broken if GDB actually needs to handle signal delivery specially,
which is in particular the case if we're currently single-stepping.
Therefore, linux-nat refrains from such by-passing of the main event
loop if single-stepping is in progress. However, it does so by simply
checking the "step" flag that was passed to its resume implementation.
But this flag will always be zero on targets that do software single-
stepping -- but those also must not bypass signal delivery ...
The patch below changes linux_nat_wait_1 to actually look at the stepping
status of the thread directly, instead of relying on the "step" flag.
This means the "currently_stepping" routine has to be exported from
infrun.c so it can be called here.
Thoughts?
Patch tested on arm-linux, i386-linux, s390-linux, powerpc-linux.
Bye,
Ulrich
ChangeLog:
* linux-nat.c (linux_nat_wait_1): Do not short-cut signal delivery
while software single-step in progress.
* inferior.h (struct thread_info): Add forward declaration.
(currently_stepping): Add prototype.
* infrun.c (currently_stepping): Remove prototype. Make global.
Index: gdb/inferior.h
===================================================================
RCS file: /cvs/src/src/gdb/inferior.h,v
retrieving revision 1.149
diff -u -p -r1.149 inferior.h
--- gdb/inferior.h 9 Jan 2011 03:08:56 -0000 1.149
+++ gdb/inferior.h 17 Jan 2011 19:15:00 -0000
@@ -31,6 +31,7 @@ struct gdbarch;
struct regcache;
struct ui_out;
struct terminal_info;
+struct thread_info;
/* For bpstat. */
#include "breakpoint.h"
@@ -253,6 +254,8 @@ extern void ensure_not_running (void);
void set_step_info (struct frame_info *frame, struct symtab_and_line sal);
+extern int currently_stepping (struct thread_info *tp);
+
/* From infcmd.c */
extern void post_create_inferior (struct target_ops *, int);
Index: gdb/infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.467
diff -u -p -r1.467 infrun.c
--- gdb/infrun.c 9 Jan 2011 03:08:56 -0000 1.467
+++ gdb/infrun.c 17 Jan 2011 19:15:05 -0000
@@ -76,8 +76,6 @@ static int follow_fork (void);
static void set_schedlock_func (char *args, int from_tty,
struct cmd_list_element *c);
-static int currently_stepping (struct thread_info *tp);
-
static int currently_stepping_or_nexting_callback (struct thread_info *tp,
void *data);
@@ -4957,7 +4979,7 @@ process_event_stop_test:
/* Is thread TP in the middle of single-stepping? */
-static int
+int
currently_stepping (struct thread_info *tp)
{
return ((tp->control.step_range_end
Index: gdb/linux-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/linux-nat.c,v
retrieving revision 1.191
diff -u -p -r1.191 linux-nat.c
--- gdb/linux-nat.c 9 Jan 2011 03:08:57 -0000 1.191
+++ gdb/linux-nat.c 17 Jan 2011 19:15:08 -0000
@@ -3604,7 +3604,7 @@ retry:
single-stepping, since that may need special care, e.g. to
skip the signal handler, or, if we're gaining control of the
inferior. */
- if (!lp->step
+ if (!currently_stepping (find_thread_ptid (lp->ptid))
&& inf->control.stop_soon == NO_STOP_QUIETLY
&& signal_stop_state (signo) == 0
&& signal_print_state (signo) == 0
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com
next reply other threads:[~2011-01-19 16:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-19 17:12 Ulrich Weigand [this message]
2011-01-19 18:48 ` Pedro Alves
2011-01-19 18:57 ` Ulrich Weigand
2011-01-19 20:40 ` Pedro Alves
2011-01-20 23:28 ` Ulrich Weigand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201101191642.p0JGgntq023362@d06av02.portsmouth.uk.ibm.com \
--to=uweigand@de.ibm.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox