gdb/
* breakpoint.c (update_breakpoints_after_exec): Don't set address to zero.
This commit is contained in:
parent
3fec76aafa
commit
e14a792bcf
|
@ -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>
|
2007-08-13 Michael Snyder <msnyder@access-company.com>
|
||||||
|
|
||||||
* valops.c: Whitespace clean-up.
|
* valops.c: Whitespace clean-up.
|
||||||
|
|
|
@ -1406,26 +1406,11 @@ update_breakpoints_after_exec (void)
|
||||||
on this target, we may not be able to stop when the vfork is
|
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
|
seen, but only when the subsequent exec is seen. (And because
|
||||||
deleting fork catchpoints here but not vfork catchpoints will
|
deleting fork catchpoints here but not vfork catchpoints will
|
||||||
seem mysterious to users, keep those too.)
|
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. */
|
|
||||||
if ((b->type == bp_catch_exec) ||
|
if ((b->type == bp_catch_exec) ||
|
||||||
(b->type == bp_catch_vfork) ||
|
(b->type == bp_catch_vfork) ||
|
||||||
(b->type == bp_catch_fork))
|
(b->type == bp_catch_fork))
|
||||||
{
|
{
|
||||||
b->loc->address = (CORE_ADDR) 0;
|
|
||||||
continue;
|
continue;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
@ -1468,17 +1453,6 @@ update_breakpoints_after_exec (void)
|
||||||
delete_breakpoint (b);
|
delete_breakpoint (b);
|
||||||
continue;
|
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? */
|
/* FIXME what about longjmp breakpoints? Re-create them here? */
|
||||||
create_overlay_event_breakpoint ("_ovly_debug_event");
|
create_overlay_event_breakpoint ("_ovly_debug_event");
|
||||||
|
|
Loading…
Reference in New Issue