From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29552 invoked by alias); 19 Jan 2011 16:43:03 -0000 Received: (qmail 29543 invoked by uid 22791); 19 Jan 2011 16:43:02 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate5.uk.ibm.com (HELO mtagate5.uk.ibm.com) (194.196.100.165) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Jan 2011 16:42:54 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate5.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p0JGgpnm005050 for ; Wed, 19 Jan 2011 16:42:51 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p0JGgrn71188028 for ; Wed, 19 Jan 2011 16:42:53 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p0JGgoaX023390 for ; Wed, 19 Jan 2011 09:42:50 -0700 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p0JGgntq023362 for ; Wed, 19 Jan 2011 09:42:49 -0700 Message-Id: <201101191642.p0JGgntq023362@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 19 Jan 2011 17:42:49 +0100 Subject: [rfc][2/2] Signal delivery + software single-step is broken To: gdb-patches@sourceware.org Date: Wed, 19 Jan 2011 17:12:00 -0000 From: "Ulrich Weigand" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-01/txt/msg00399.txt.bz2 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