This is the mail archive of the
mailing list for the GDB project.
Re: breakpoints in shared libraries
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Gdb List <gdb at sources dot redhat dot com>
- Date: Sun, 25 Nov 2001 13:37:12 -0500
- Subject: Re: breakpoints in shared libraries
- References: <firstname.lastname@example.org>
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