* ada-lang.c (resolve_subexp): Correct arity of binary operators.

[deliverable/binutils-gdb.git] / gdb / breakpoint.c

diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index 8c27a24ae94ccb400af8d5fe5148f712712ab56f..f798710dfb83e3c723d40c8bda0eac9ab8ef16ce 100644 (file)
--- 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");
@@ -3414,7 +3388,7 @@ print_one_breakpoint (struct breakpoint *b,
 
   /* 2 */
   annotate_field (1);
-  if (((int) b->type > (sizeof (bptypes) / sizeof (bptypes[0])))
+  if (((int) b->type >= (sizeof (bptypes) / sizeof (bptypes[0])))
       || ((int) b->type != bptypes[(int) b->type].type))
     internal_error (__FILE__, __LINE__,
                    _("bptypes table does not describe type #%d."),
@@ -4474,7 +4448,7 @@ create_solib_event_breakpoint (CORE_ADDR address)
    apply to enabled breakpoints, disabled ones can just stay disabled.  */
 
 void
-disable_breakpoints_in_shlibs (int silent)
+disable_breakpoints_in_shlibs (void)
 {
   struct breakpoint *b;
   int disabled_shlib_breaks = 0;
@@ -4489,19 +4463,7 @@ disable_breakpoints_in_shlibs (int silent)
        && solib_address (b->loc->address)
 #endif
        )
-      {
        b->enable_state = bp_shlib_disabled;
-       if (!silent)
-         {
-           if (!disabled_shlib_breaks)
-             {
-               target_terminal_ours_for_output ();
-               warning (_("Temporarily disabling shared library breakpoints:"));
-             }
-           disabled_shlib_breaks = 1;
-           warning (_("breakpoint #%d "), b->number);
-         }
-      }
   }
 }