Under GDB 5.x on at least some platforms (Linux, e.g.) the command
break
has an effect that departs significantly from GDB 4.x. The sequence
of commands
(gdb) run
...
<stopped at location FOO for any reason>
(gdb) break
Breakpoint 42 at 0x8049653: file foo.c, line 100.
(gdb) run
...
will NOT generally stop at breakpoint 42; in fact that breakpoint will
be removed. In both 4.x and 5.x such breakpoints are removed like
this only if the symbol tables were reloaded. When that happens,
breakpoint_re_set re-sets all breakpoints. Those without an
addr_string (that is those for which only the text address of the
breakpoint is recorded) would be deleted on the theory that reloading
the symbol tables generally goes along with changing the executable
text and invalidating all specific instruction addresses.
Under 5.x (again, I'm talking Linux, but I presume other platforms are
affected) the shared-library symbol tables are reloaded on each 'run',
so that no plain 'break' survives. I'd be happy to fix this, but what
to "blame"? Clearly, you don't want to dummy up an addr_string such
as "*0x8049653" because then you get weird effects when addresses DO
change. Pardon my ignorance of shared library internals in general,
but SHOULD these symbol tables be reloaded in the absence of change to
the executable?
Anyway, comments appreciated.
Paul Hilfinger
_______________________________________________
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb
