From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26835 invoked by alias); 11 Dec 2004 18:01:31 -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 26821 invoked from network); 11 Dec 2004 18:01:28 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 11 Dec 2004 18:01:28 -0000 Received: from zaretski (pns03-203-109.inter.net.il [80.230.203.109]) by legolas.inter.net.il (MOS 3.5.5-GR) with ESMTP id DHV07074 (AUTH halo1); Sat, 11 Dec 2004 20:00:48 +0200 (IST) Date: Sat, 11 Dec 2004 18:02:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-ID: <01c4dfab$Blat.v2.2.2$8112a160@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: jjohnstn@redhat.com, gdb-patches@sources.redhat.com In-reply-to: <20041211173256.GA15506@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 11 Dec 2004 12:32:56 -0500) Subject: Re: [RFA]: Modified Watchthreads Patch Reply-to: Eli Zaretskii References: <41B8E16D.6070505@redhat.com> <20041210191015.GA18430@nevyn.them.org> <01c4df0c$Blat.v2.2.2$244dda20@zahav.net.il> <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> X-SW-Source: 2004-12/txt/msg00309.txt.bz2 > Date: Sat, 11 Dec 2004 12:32:56 -0500 > From: Daniel Jacobowitz > Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com > > I think that every current use of observers is in this sense "we don't > really know in advance what needs to be done". For instance, we've got > observer_notify_inferior_created, which is uesd for actions that we > don't know statically will be necessary at inferior creation - vsyscall > DSO loading on targets which have one, and some HP/UX specific code > that I don't recall the purpose of. > > Or consider target_changed, which is attached by the frame code (always > part of GDB!) and the regcache (likewise!) and notified by valops.c > (likewise!). What about solib_unloaded? > 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. As for its documentation, it boils down to a couple of sentences, so I don't think it's a big deal.