- displaced->step_closure
- = gdbarch_displaced_step_copy_insn (gdbarch, original, copy, regcache);
- if (displaced->step_closure == NULL)
- {
- /* The architecture doesn't know how or want to displaced step
- this instruction or instruction sequence. Fallback to
- stepping over the breakpoint in-line. */
- return -1;
- }
+ if (debug_displaced)
+ fprintf_unfiltered (gdb_stdlog,
+ "displaced: not enough resources available, "
+ "deferring step of %s\n",
+ target_pid_to_str (tp->ptid).c_str ());
+
+ global_thread_step_over_chain_enqueue (tp);
+ tp->inf->displaced_step_state.unavailable = true;
+
+ return DISPLACED_STEP_PREPARE_STATUS_UNAVAILABLE;
+ }
+
+ gdb_assert (status == DISPLACED_STEP_PREPARE_STATUS_OK);
+
+// FIXME: Should probably replicated in the arch implementation now.
+//
+// if (breakpoint_in_range_p (aspace, copy, len))
+// {
+// /* There's a breakpoint set in the scratch pad location range
+// (which is usually around the entry point). We'd either
+// install it before resuming, which would overwrite/corrupt the
+// scratch pad, or if it was already inserted, this displaced
+// step would overwrite it. The latter is OK in the sense that
+// we already assume that no thread is going to execute the code
+// in the scratch pad range (after initial startup) anyway, but
+// the former is unacceptable. Simply punt and fallback to
+// stepping over this breakpoint in-line. */
+// if (debug_displaced)
+// {
+// fprintf_unfiltered (gdb_stdlog,
+// "displaced: breakpoint set in scratch pad. "
+// "Stepping over breakpoint in-line instead.\n");
+// }
+//
+// gdb_assert (false);
+// gdbarch_displaced_step_release_location (gdbarch, copy);
+//
+// return -1;
+// }