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