[commit] update_breakpoints_after_exec

[Vladimir Prus <vladimir at codesourcery dot com>]

The update_breakpoints_after_exec sets breakpoint
address to zero in a couple of places. Both places
have a comment that say setting address to zero has
no effect, and after being over breakpoint.c for quite
some time, I have the same conclusion.
Finally, removing this assignment does not break any tests.
The attached patch, approved off-list by Jim Blandy and
checked in, removes this stale code.

- Volodya

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.8607
diff -u -p -r1.8607 ChangeLog
--- ChangeLog	14 Aug 2007 00:31:35 -0000	1.8607
+++ ChangeLog	14 Aug 2007 08:11:00 -0000
@@ -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.
Index: breakpoint.c
===================================================================
RCS file: /cvs/src/src/gdb/breakpoint.c,v
retrieving revision 1.258
diff -u -p -r1.258 breakpoint.c
--- breakpoint.c	5 Aug 2007 00:43:34 -0000	1.258
+++ breakpoint.c	14 Aug 2007 08:11:01 -0000
@@ -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");