Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Cc: "Ulrich Weigand" <uweigand@de.ibm.com>,
	 Julian Brown <julian@codesourcery.com>,
	 Daniel Jacobowitz <drow@false.org>
Subject: Re: [rfc] Fix PowerPC displaced stepping regression
Date: Mon, 28 Sep 2009 17:31:00 -0000	[thread overview]
Message-ID: <200909281831.45115.pedro@codesourcery.com> (raw)
In-Reply-To: <200909281712.n8SHCidf006302@d12av02.megacenter.de.ibm.com>

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


  reply	other threads:[~2009-09-28 17:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-20 22:14 [PATCH] Displaced stepping (non-stop debugging) support for ARM Linux Julian Brown
2009-01-21 18:07 ` Pedro Alves
2009-02-02 20:01 ` Daniel Jacobowitz
2009-05-16 18:19   ` Julian Brown
2009-06-09 17:37     ` Daniel Jacobowitz
2009-06-10 14:58       ` Pedro Alves
2009-06-10 15:05         ` Daniel Jacobowitz
2009-07-15 19:16           ` Julian Brown
2009-07-24  2:17             ` Daniel Jacobowitz
2009-07-31 11:43             ` Julian Brown
2009-09-24 19:35               ` Ulrich Weigand
2009-09-27 21:47                 ` [rfc] Fix PowerPC displaced stepping regression Ulrich Weigand
2009-09-28 16:57                   ` Pedro Alves
2009-09-28 17:12                     ` Ulrich Weigand
2009-09-28 17:31                       ` Pedro Alves [this message]
2009-09-28 17:39                         ` Ulrich Weigand
2009-09-28 17:27                     ` Ulrich Weigand
2009-09-28 17:39                       ` Pedro Alves
2009-09-28 17:45                         ` Ulrich Weigand
2009-09-28 19:07                           ` Pedro Alves
2009-09-28 19:41                   ` Pedro Alves
2009-09-29  0:59                     ` Ulrich Weigand
2009-09-29  1:36                       ` Joel Brobecker
2009-09-29 12:54                         ` 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=200909281831.45115.pedro@codesourcery.com \
    --to=pedro@codesourcery.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sourceware.org \
    --cc=julian@codesourcery.com \
    --cc=uweigand@de.ibm.com \
    /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