From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12917 invoked by alias); 28 Sep 2009 17:31:37 -0000 Received: (qmail 12899 invoked by uid 22791); 28 Sep 2009 17:31:37 -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 17:31:32 +0000 Received: (qmail 24981 invoked from network); 28 Sep 2009 17:31:30 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 28 Sep 2009 17:31:30 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [rfc] Fix PowerPC displaced stepping regression Date: Mon, 28 Sep 2009 17:31:00 -0000 User-Agent: KMail/1.9.10 Cc: "Ulrich Weigand" , Julian Brown , Daniel Jacobowitz References: <200909281712.n8SHCidf006302@d12av02.megacenter.de.ibm.com> In-Reply-To: <200909281712.n8SHCidf006302@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: <200909281831.45115.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/msg00871.txt.bz2 On Monday 28 September 2009 18:12:44, Ulrich Weigand wrote: > Pedro Alves wrote: > > > On Sunday 27 September 2009 22:47:13, Ulrich Weigand wrote: > > > - 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? > > I'm not sure which "particular predicate" you're referring to, sorry ... > > The check currently reads: > > if (use_displaced_stepping (gdbarch) > && (tp->trap_expected > || (step && gdbarch_software_single_step_p (gdbarch))) > && sig == TARGET_SIGNAL_0) > > that is, if we'd otherwise be about to issue a single step (potentially) > treat it like stepping over a breakpoint. At what point would you > suggest to check for non_stop? At the points where we decide to use displaced stepping because software single-stepping doesn't work with multiple pending simultaneous requests. So, adding a non_stop check there in front of software_single_step_p, if (use_displaced_stepping (gdbarch) && (tp->trap_expected - || (step && gdbarch_software_single_step_p (gdbarch))) + || (non_stop && step && gdbarch_software_single_step_p (gdbarch))) ... and in maybe_software_singlestep: - if (use_displaced_stepping (gdbarch)) - if (non_stop) hw_step = 0; (or make resume clear `step' if "non_stop && step && gdbarch_software_single_step_p (gdbarch))" so to we'd not reach maybe_software_singlestep at all. But, let's ignore this. The only benefit would be for all-stop + displaced stepping=on to not trigger displaced stepping all the way. > > Did you consider making the gdbarch_displaced_step_copy_insn > > callback itself return that it expects the target to be > > continued instead of stepped? > > Yes, but this would have required changes to the existing gdbarch > interface that would have meant updating all existing users; and > I wanted to produce a patch that doesn't touch any platform I > cannot test at this point ... > > In any case, the two interfaces should be pretty much identical: > a target can simply set a flag in its "closure" and return this > flag from the displaced_step_hw_singlestep routine. That's why > I'm passing the closure in, even though PPC doesn't need it ... True. I like that! -- Pedro Alves