From: Vladimir Prus <vladimir@codesourcery.com>
Date: Tue, 14 Aug 2007 08:11:45 +0000 (+0000)
Subject:         gdb/
X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=e14a792bcf5d14059f9d991873b94083c9a1bc3b;p=binutils-gdb.git

    gdb/
        * breakpoint.c (update_breakpoints_after_exec): Don't
        set address to zero.
---

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index bcf9f7bc6f2..9f58c40ec8d 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,9 @@
+2007-08-14  Vladimir Prus  <vladimir@codesourcery.com>
+
+	gdb/
+	* breakpoint.c (update_breakpoints_after_exec): Don't
+	set address to zero.
+
 2007-08-13  Michael Snyder  <msnyder@access-company.com>
 
 	* valops.c: Whitespace clean-up.
diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index f59f1da143c..1fc3d104956 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -1406,26 +1406,11 @@ update_breakpoints_after_exec (void)
        on this target, we may not be able to stop when the vfork is
        seen, but only when the subsequent exec is seen.  (And because
        deleting fork catchpoints here but not vfork catchpoints will
-       seem mysterious to users, keep those too.)
-
-       ??rehrauer: Let's hope that merely clearing out this catchpoint's
-       target address field, if any, is sufficient to have it be reset
-       automagically.  Certainly on HP-UX that's true.
-
-       Jim Blandy <jimb@redhat.com>: Actually, zero is a perfectly
-       valid code address on some platforms (like the mn10300
-       simulators).  We shouldn't assign any special interpretation to
-       a breakpoint with a zero address.  And in fact, GDB doesn't ---
-       I can't see what that comment above is talking about.  As far
-       as I can tell, setting the address of a
-       bp_catch_exec/bp_catch_vfork/bp_catch_fork breakpoint to zero
-       is meaningless, since those are implemented with HP-UX kernel
-       hackery, not by storing breakpoint instructions somewhere.  */
+       seem mysterious to users, keep those too.)  */
     if ((b->type == bp_catch_exec) ||
 	(b->type == bp_catch_vfork) ||
 	(b->type == bp_catch_fork))
       {
-	b->loc->address = (CORE_ADDR) 0;
 	continue;
       }
 
@@ -1468,17 +1453,6 @@ update_breakpoints_after_exec (void)
 	delete_breakpoint (b);
 	continue;
       }
-
-    /* If this breakpoint has survived the above battery of checks, then
-       it must have a symbolic address.  Be sure that it gets reevaluated
-       to a target address, rather than reusing the old evaluation.
-
-       Jim Blandy <jimb@redhat.com>: As explained above in the comment
-       for bp_catch_exec and friends, I'm pretty sure this is entirely
-       unnecessary.  A call to breakpoint_re_set_one always recomputes
-       the breakpoint's address from scratch, or deletes it if it can't.
-       So I think this assignment could be deleted without effect.  */
-    b->loc->address = (CORE_ADDR) 0;
   }
   /* FIXME what about longjmp breakpoints?  Re-create them here?  */
   create_overlay_event_breakpoint ("_ovly_debug_event");