From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25292 invoked by alias); 11 Feb 2005 17:17:56 -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 25261 invoked from network); 11 Feb 2005 17:17:52 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 11 Feb 2005 17:17:52 -0000 Received: from drow by nevyn.them.org with local (Exim 4.44 #1 (Debian)) id 1CzeQR-0008FK-4v; Fri, 11 Feb 2005 12:17:51 -0500 Date: Fri, 11 Feb 2005 18:31:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [RFA]: Modified Watchthreads Patch Message-ID: <20050211171751.GA31423@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , jjohnstn@redhat.com, gdb-patches@sources.redhat.com References: <20041210230603.GA23419@nevyn.them.org> <01c4df10$Blat.v2.2.2$6f63d1a0@zahav.net.il> <20041210233700.GA24439@nevyn.them.org> <01c4df73$Blat.v2.2.2$5e13b740@zahav.net.il> <20041211161136.GA13865@nevyn.them.org> <01c4dfa2$Blat.v2.2.2$486cc380@zahav.net.il> <20041211173256.GA15506@nevyn.them.org> <41E6CA85.5090407@redhat.com> <20050210195838.GA12332@nevyn.them.org> <01c5105b$Blat.v2.4$bb9e28a0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c5105b$Blat.v2.4$bb9e28a0@zahav.net.il> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-02/txt/msg00107.txt.bz2 On Fri, Feb 11, 2005 at 07:03:20PM +0200, Eli Zaretskii wrote: > Perhaps I misunderstood, but the above 2 alternatives don't use > observers. And since these are Linux-specific issues, I left it to > Daniel and you to select the best alternative. > > In other words, I don't think you need any input from me to decide how > to solve this. Am I missing something? No, you aren't. For this problem, we're set. However, I'd like to discuss the design principle for a bit, so that we know how to approach this problem in the future. I found the message I was thinking of. I wrote: > > Observe, we're back to the core question of the role of observers here. > > I prefer #2 to #1. But #2 is _functionally_ equivalent to providing an > > observer named linux_enable_watchpoints_for_new_threads. > > It is functionally equivalent, but ideologically different: it's a > detail of GDB internals as opposed to a general-purpose extension > mechanism. I do not consider GDB's observer mechanism to be a general-purpose extension mechanism. Some day, if there is a revival of libgdb, then maybe it will be usable as one - and at that point, perhaps we'll need a second copy with different events. I think the current observers are a mechanism for nominally independent internal modules of GDB to communicate. Are "breakpoint" and "shared library" any more independent than "common Linux support" and "some particular Linux backend"? Maybe so, but the line seems pretty shaky to me. Certainly the breakpoint module has a lot of code to handle shared libraries, and the shared library code makes use of breakpoints. My current feeling is that either: (A) we should use the same mechanism to create two sets of hooks, one to be considered a general extension mechanism and the other an internal modularity aid; or (B) we should define the observers as the latter rather than the former, and declare the former niche unfilled. Otherwise there's just a lot of wasted code duplication. What do you think? Am I way off on the role of observers? Since we don't "support" plugging arbitrary code into them, I have trouble considering them an extension mechanism. -- Daniel Jacobowitz CodeSourcery, LLC