Re: breakpoints in shared libraries

[Daniel Jacobowitz <drow@mvista.com>]

On Sun, Nov 25, 2001 at 11:30:21AM -0700, Tom Tromey wrote:
> A while back I changed Insight so that it would save and restore
> breakpoints.  This is really handy, but it has a problem that I think
> requires changes to gdb itself.
> 
> Suppose I set a breakpoint in a shared library.  I find on my Linux
> box I can only do this after the inferior has been started.  So I use
> `b main', then `run', then set the breakpoints I really care about.
> (This gets old fast, btw.)
> 
> When Insight saves breakpoints, it doesn't know about this.  How could
> it?  So it saves everything.  When I restart Insight and load my old
> session, the breakpoints that are interesting to me don't load,
> because gdb doesn't yet know about the shared libraries.
> 
> How can this be fixed?  I don't know the answer.  One idea I had is to
> annotate each breakpoint with information about what shared library it
> comes from.  Then, defer processing for that breakpoint until the
> shared library is actually loaded by the inferior.
> 
> Maybe there would be other ways to accomplish the same thing.  It
> would be nice if I didn't ever have to do the whole `b main; r' thing
> in the first place.  But as it stands this problem is a real
> impediment to my typical uses for gdb.

I think the best approach for this is to expose an interface to create
shlib_disabled breakpoints.  Then they'll be automatically re-enabled
when the library containing that symbol is loaded.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer