Re: Breakpoints in dynamically loaded objects

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   From: Jim Blandy <jimb@zwingli.cygnus.com>
   Date: 08 May 2000 09:49:15 -0500

   I tend to agree that breakpoint_re_set_one shouldn't delete a
   shlib_disabled breakpoint just because it can't find the symbol; it
   should leave it shlib_disabled.

Well, it doesn't *delete* the breakpoint, only disables it (unless
addr_string isn't set).  But we agree that it shouldn't do that to
breakpoints that are shlib_disabled.

   However, that would mean that, if you're doing shared library work and
   you really do rename a function that had a breakpoint set on it, that
   old breakpoint will just sit around forever.  I'm not sure what to do
   with that.

Since these breakpoints won't be deleted anyway, I don't think this is
something we should worry about right now.

   re_enable_breakpoints_in_shlibs looks wrong to me, too.  Shlibs can be
   loaded at a different address every time, so b->address may not be
   valid.  Of course, the shlibs that are were specified at link time
   will most likely appear at the same address each time, but libraries
   loaded by hand may not.  

OK, but loading a shlib will cause GDB to load its symbols, which will
call breakpoint_re_set().  So we could set b->address to NULL if we
couldn't find the the right location for a shlib_disabled breakpoint.
That should prevent re_enable_breakpoints_in_shlibs from setting it at
memory that is now in use by another shlib.

Anyway, leaving shlib_disabled breakpoints shlib_disabled in
breakpoint_re_set_one seems to do the job.  I'll look a bit closer at
what happens if we reset b->address for shlib_disabled breakpoints in breakpoint_re_set_one.

Mark