From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18367 invoked by alias); 11 Aug 2004 20:47:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18320 invoked from network); 11 Aug 2004 20:47:13 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 11 Aug 2004 20:47:13 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1Buzzv-00022F-ER; Wed, 11 Aug 2004 16:46:59 -0400 Date: Wed, 11 Aug 2004 20:47:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Eli Zaretskii , jjohnstn@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFA]: Fix for pending breakpoints in manually loaded/unloaded shlibs Message-ID: <20040811204658.GA7231@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Eli Zaretskii , jjohnstn@redhat.com, gdb-patches@sources.redhat.com References: <41191D71.60204@redhat.com> <7494-Wed11Aug2004070352+0300-eliz@gnu.org> <411A4209.6020801@redhat.com> <411A5012.3000508@gnu.org> <9743-Wed11Aug2004205531+0300-eliz@gnu.org> <411A84B0.7020106@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <411A84B0.7020106@gnu.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-08/txt/msg00409.txt.bz2 On Wed, Aug 11, 2004 at 04:42:24PM -0400, Andrew Cagney wrote: > >>Date: Wed, 11 Aug 2004 12:57:54 -0400 > >>>From: Andrew Cagney > >>> > >>>Right. In addition to the breakpoints, the MI needs to know about these > >>>identical events (so that it can notify the gui of an shlib unload). > > > > > >Not that I'm against this, but perhaps instead of implementing a core > >GDB feature based on the observers (which, as far as I understand, > >were invented for a different purpose), we should talk about two > >separate changes: one that adds the observer, and another that fixes > >the problem reported by Jeff. > > Um, observers were introduced for this purpose - make it possible for > anything, core or peripheral, to monitor changes in the inferior/GDB. > Otherwize we end up with things like this. > > observer_notify_solib_unloaded (...); > breakpoint_notify_solib_unloaded (...); > > I'm currently investigating gdb.threads/static.exp failures and to fix > that I think I'll need to add a further observer event. Really? I think thread-db needs to try to initialize at two points: whenever a new shared library is loaded (converting the objfile hook to an observer would be nice, but independent) and whenever an inferior is created (conveniently we've got an observer for this already). -- Daniel Jacobowitz