[PATCH 9/9] Non-stop + software single-step archs: don't force displaced-stepping for all single-steps

[Pedro Alves <palves at redhat dot com>]

This finally reverts this bit of commit 929dfd4f:

  2009-07-31  Pedro Alves  <pedro@codesourcery.com>
	      Julian Brown  <julian@codesourcery.com>

	 ...
	 (resume): If this is a software single-stepping arch, and
	 displaced-stepping is enabled, use it for all single-step
	 requests.
	 ...

That means that in non-stop (or really displaced-stepping) mode, on
software single-step archs - even those that only use sss breakpoints
to deal with atomic sequences, like PPC - if we have more than one
thread single-stepping, we'll always serialize the threads'
single-steps, as only one thread may be displaced stepping at a given
time, because there's only one scratch pad.

We originally did that because GDB didn't support having multiple
threads software-single-stepping simultaneously.  The previous patches
fixed that limitation, so we can now finally revert this too.

Tested on:

  - x86_64 Fedora 20, on top of the 'software single-step on x86'
    series.
  - PPC64 Fedora 18  (installs gdbarch_software_single_step hook to
    deal with atomic sequences).

gdb/
2014-09-25  Pedro Alves  <palves@redhat.com>

	* infrun.c (resume): Don't force displaced-stepping for all
	single-steps on software single-stepping archs.
---
 gdb/infrun.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gdb/infrun.c b/gdb/infrun.c
index 4ff5b07..e51bc7c 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -1846,8 +1846,7 @@ a command like `return' or `jump' to continue execution."));
      event, displaced stepping breaks the vfork child similarly as single
      step software breakpoint.  */
   if (use_displaced_stepping (gdbarch)
-      && (tp->control.trap_expected
-	  || (step && gdbarch_software_single_step_p (gdbarch)))
+      && tp->control.trap_expected
       && sig == GDB_SIGNAL_0
       && !current_inferior ()->waiting_for_vfork_done)
     {
-- 
1.9.3