This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Breakpoints in dynamically loaded objects
- To: gdb at sources dot redhat dot com
- Subject: Re: Breakpoints in dynamically loaded objects
- From: Tom Tromey <tromey at cygnus dot com>
- Date: 08 May 2000 10:34:55 -0600
- Newsgroups: cygnus.gdb
- Organization: Cygnus Solutions
- References: <200005081343.e48DhHu06845@delius.kettenis.local> <npzoq1cd1w.fsf@zwingli.cygnus.com>
- Reply-To: tromey at cygnus dot com
>>>>> "Jim" == Jim Blandy <jimb@zwingli.cygnus.com> writes:
Jim> However, that would mean that, if you're doing shared library
Jim> work and you really do rename a function that had a breakpoint
Jim> set on it, that old breakpoint will just sit around forever. I'm
Jim> not sure what to do with that.
Nothing. It doesn't matter. Although I do sometimes leave gdb
running a long time (days), the overhead (actual and conceptual)
associated with a useless breakpoint is less than the agony of
constantly rediscovering that gdb has silently disabled breakpoints.
Try debugging a Java program that uses JNI some time. It should be
easy, but it isn't. You have to set a bp on main and then run before
you can set a breakpoint on any function the Java class library. Then
you have to set a breakpoint on an internal function in libgcj,
continue, and then finish, before you can set a breakpoint on the JNI
function loaded from the shared library.
Then if you need to re-run, you get to go through this process again.
And, because of the need to "finish" on that second breakpoint before
enabling the JNI breakpoint, you can't automate it.
Tom