From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23655 invoked by alias); 27 Apr 2011 19:12:13 -0000 Received: (qmail 23641 invoked by uid 22791); 27 Apr 2011 19:12:12 -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 mtagate7.uk.ibm.com (HELO mtagate7.uk.ibm.com) (194.196.100.167) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 27 Apr 2011 19:11:57 +0000 Received: from d06nrmr1806.portsmouth.uk.ibm.com (d06nrmr1806.portsmouth.uk.ibm.com [9.149.39.193]) by mtagate7.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p3RJBtUL010329 for ; Wed, 27 Apr 2011 19:11:55 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1806.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3RJCw3N2007118 for ; Wed, 27 Apr 2011 20:12:59 +0100 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 p3RJBsN3005692 for ; Wed, 27 Apr 2011 13:11:54 -0600 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 p3RJBrEY005667; Wed, 27 Apr 2011 13:11:53 -0600 Message-Id: <201104271911.p3RJBrEY005667@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 27 Apr 2011 21:11:53 +0200 Subject: Re: [commit] Re: [rfc][1/2] Signal delivery + software single-step is broken To: pedro@codesourcery.com (Pedro Alves) Date: Wed, 27 Apr 2011 19:12:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <201104271915.05190.pedro@codesourcery.com> from "Pedro Alves" at Apr 27, 2011 07:15:04 PM 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-04/txt/msg00526.txt.bz2 Pedro Alves wrote: > On Wednesday 27 April 2011 18:17:25, Ulrich Weigand wrote: > > + /* Stepping over a breakpoint while at the same time delivering a signal > > + has a problem: we cannot use displaced stepping, but we also cannot > > + use software single-stepping, because we do not know where execution > > + will continue if a signal handler is installed. > > + > > + On the other hand, if there is a signal handler we'd have to step > > + over it anyway. So what we do instead is to install a step-resume > > + handler at the current address right away, deliver the signal without > > + stepping, and once we arrive back at the step-resume breakpoint, step > > + once more over the original breakpoint we wanted to step over. */ > > + if (oneproc && tp->suspend.stop_signal != TARGET_SIGNAL_0 > > + && execution_direction != EXEC_REVERSE) > > + { > > + insert_step_resume_breakpoint_at_frame (get_current_frame ()); > > + tp->step_after_step_resume_breakpoint = 1; > > + oneproc = 0; > > + } > > This unfortunately somewhat breaks hardware-step archs: > > (the below is a simple program that writes to 0, and has a > SIGSEGV handler installed) > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004008ca in main2 () at siginfo.c:104 > 104 *(int *)p = 0; > (gdb) b > Breakpoint 1 at 0x4008ca: file siginfo.c, line 104. > (gdb) si That's an interesting test case :-) The problem is that if a step-resume breakpoint is installed, handle_inferior_event will never expect hardware single-step traps (unless a software watchpoint is also in effect), because it assumes nobody ever uses a step-resume breakpoint and then hardware single-steps as well (because currently_stepping returns 0 in that case). The simple way to fix the inconsistency would be to just add a step = 0; line to the above if. Of course this changes the behaviour for hardware single-step platforms: they now would not step into the signal handler in this case (just like software single-step platforms don't). On the one hand, this adds consistency: both types of platforms behave the same. (On software single-step platforms, it seems we simply cannot step into the handler, because we can't find it.) On the other hand, in some sense this reduces functionality. So one could try to treat the two platforms separately, and have hardware single-step platforms step into the handler, even while software single-step platforms don't. [ This would probably mean to move support back into resume, because we'd want to do that only if we actually use software single-step for this particular step. ] Thoughts? Which behaviour would you prefer? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com