From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7081 invoked by alias); 28 Sep 2009 16:57:43 -0000 Received: (qmail 6992 invoked by uid 22791); 28 Sep 2009 16:57:41 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Sep 2009 16:57:37 +0000 Received: (qmail 4950 invoked from network); 28 Sep 2009 16:57:35 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Sep 2009 16:57:35 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [rfc] Fix PowerPC displaced stepping regression Date: Mon, 28 Sep 2009 16:57:00 -0000 User-Agent: KMail/1.9.10 Cc: "Ulrich Weigand" , Julian Brown , Daniel Jacobowitz References: <200909272147.n8RLlDCU031811@d12av02.megacenter.de.ibm.com> In-Reply-To: <200909272147.n8RLlDCU031811@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909281757.49385.pedro@codesourcery.com> X-IsSubscribed: yes 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: 2009-09/txt/msg00868.txt.bz2 On Sunday 27 September 2009 22:47:13, Ulrich Weigand wrote: > I wrote: > > It seems this change broke displaced stepping on PowerPC. > > > > I'm not sure I understand the rationale behind these changes to the > > displaced stepping logic in infrun.c in the first place. Why is > > everything conditioned on gdbarch_software_single_step_p, which just > > says whether or not the architecture has installed a single-stepping > > routine -- but this alone doesn't say whether software stepping is > > actually needed in any given situation ... > > OK, it seems there are two separate changes: > > - In non-stop mode, we never want to use software single-step as > common code does not support this in multiple threads at once. Right. Shouldn't we switch this particular predicate to check the non_stop global instead? > - On platforms with no hardware single-step available, GDB common > code should not use "step" but "continue" to run displaced copies. > > The first change does make sense, also on PowerPC. It is in fact > the second change that is problematic, as it would force PowerPC > to implement a much more complex displaced stepping logic just to > avoid using hardware single-stepping the displaced copies .. which > there is no need for in the first place. > > The following patch keeps the first change, but makes the second > change conditional on a new gdbarch callback instead of simply > checking for gdbarch_software_single_step_p. This allows PowerPC > to say that even though it has installed a SW single-step routine > to handle some specific corner cases, it still wants to use HW > stepping for displaced copies. The default is such that everything > should be unchanged for the ARM case. Did you consider making the gdbarch_displaced_step_copy_insn callback itself return that it expects the target to be continued instead of stepped? I see that it's arm-tdep.c:arm_displaced_init_closure itself that inserts a breakpoint after the relocated instructions. An original insn can be expanded to more than one instruction, at displaced_step_copy time, so it can be useful to say "continue" instead of several single-step even if the target supported HW step, and this addresses the ppc/arm issue as well. So, displaced_step_prepare would propagate the "continue" vs "step" up, and all its callers would do the old logic: if (step) { if (gdbarch_software_single_step_p (gdbarch)) target_resume (ptid, 0, TARGET_SIGNAL_0); else target_resume (ptid, 1, TARGET_SIGNAL_0); } else target_resume (ptid, 0, TARGET_SIGNAL_0); ... that is, we'd remove the checks for use_displaced_stepping from maybe_software_singlestep, and use something like the above in displaced_step_fixup, where we issue the target_resume (with `step' being what gdbarch_displaced_step_copy_insn reported it wanted). -- Pedro Alves