From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tom Tromey <tromey@cygnus.com>
To: gdb@sources.redhat.com
Subject: Re: Breakpoints in dynamically loaded objects
Date: Wed, 05 Sep 2001 00:12:00 -0000
Message-id: <874s89ov9s.fsf@cygnus.com>
References: <200005081343.e48DhHu06845@delius.kettenis.local> <npzoq1cd1w.fsf@zwingli.cygnus.com>
X-SW-Source: 2001-09/msg00024.html

>>>>> "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