FreeChainXenon/binutils-gdb
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

gdb/

Browse source 
* breakpoint.c (update_breakpoints_after_exec): Don't
        set address to zero.
This commit is contained in:
Vladimir Prus 2007-08-14 08:11:45 +00:00
parent 3fec76aafa
commit e14a792bcf
2 changed files with 7 additions and 27 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
gdb/ChangeLog
View file

@ -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.

28
gdb/breakpoint.c
View file

@ -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");