gdb/record-full: Use xmalloc instead of alloca for temporary memory storage.
[deliverable/binutils-gdb.git] / gdb / infrun.c
index 917f9beffffe05ced296a09a8bce253e47a2ed75..ef4ccb4e7fa27791917aa49238cfc26655923602 100644 (file)
@@ -1729,6 +1729,7 @@ displaced_step_prepare_throw (ptid_t ptid)
   struct thread_info *tp = find_thread_ptid (ptid);
   struct regcache *regcache = get_thread_regcache (ptid);
   struct gdbarch *gdbarch = get_regcache_arch (regcache);
+  struct address_space *aspace = get_regcache_aspace (regcache);
   CORE_ADDR original, copy;
   ULONGEST len;
   struct displaced_step_closure *closure;
@@ -1784,6 +1785,28 @@ displaced_step_prepare_throw (ptid_t ptid)
   copy = gdbarch_displaced_step_location (gdbarch);
   len = gdbarch_max_insn_length (gdbarch);
 
+  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");
+       }
+
+      do_cleanups (old_cleanups);
+      return -1;
+    }
+
   /* Save the original contents of the copy area.  */
   displaced->step_saved_copy = (gdb_byte *) xmalloc (len);
   ignore_cleanups = make_cleanup (free_current_contents,
This page took 0.025437 seconds and 4 git commands to generate.