From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23110 invoked by alias); 11 Dec 2004 16:11:58 -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 23013 invoked from network); 11 Dec 2004 16:11:50 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 11 Dec 2004 16:11:50 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1Cd9qL-0003ex-9h; Sat, 11 Dec 2004 11:11:37 -0500 Date: Sat, 11 Dec 2004 16:37: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: <20041211161136.GA13865@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , jjohnstn@redhat.com, gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4df73$Blat.v2.2.2$5e13b740@zahav.net.il> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-12/txt/msg00298.txt.bz2 On Sat, Dec 11, 2004 at 01:19:03PM +0200, Eli Zaretskii wrote: > > Date: Fri, 10 Dec 2004 18:37:00 -0500 > > From: Daniel Jacobowitz > > Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com > > > > I waited to review the revised version until you had a chance to > > comment on the continued use of observers. > > I still object to the use of observers for a purpose such as this one. > My objections are a bit philosophical, though. That's a fine kind of objection :-) > Basically, I think that observers are a last-resort mechanism for > anything that is part of the GDB infrastructure. It's like hooks or > callbacks--you don't normally expect a program internals to use > callbacks that it provides for higher-level application code. > > Put another way, using a mechanism such as observers for internal code > means we leave our internal structure not entirely defined. We design > the internals, so we ought to know what needs to be done where and > when. For example, this particular usage of an observer means that we > don't really know in advance that watchpoint insertion needs to be > done for each thread when it is being attached. Do we really want to > say that we don't know what we are doing in our own program? As Mark said, the idea is that GDB is modular. If we knew that every time the GNU/Linux native support code was used, the architecture native support code would need to munge watchpoints in this way, and there were few other platforms for which it was true, then using an observer would be silly. But we aren't supposed to "know" what architecture is in use when we compile linux-nat.c, and this action is a property of the architecture. Are there really any current uses of observers which meet your definition above? That said, it looks like all Linux targets (with the exception of the current x86 mystery) have this behavior. That gives me at least two more ideas on how to implement it. 1) Wait for my target vector inheritance patch to go in. Have the target override either to_wait or to_resume - probably to_resume. In the overridden version, iterate over all LWPs and make sure watchpoints are correctly inserted for them all. Disadvantage: we shouldn't need to iterate over the entire LWP list for this. But there are enough places in GDB that don't scale easily to huge LWP lists that I can't imagine this one being a problem in the next ten years. 2) Provide a GNU/Linux specific hook, not using the observer mechanism, in the same way we've been connecting architectures to other individual modules of GDB. Implement linux_set_new_thread_watchpoints_callback, which would be functionally similar to this observer, but have a better defined purpose and use. Are either of these better? > In addition, proliferation of observers' use will sooner or later > raise the issue of the order of the observer invocation, since we lack > a machinery for invoking a series of observers in a controlled manner: > we cannot control the order of their invocation and we cannot tell GDB > to stop invoking any additional observers. The current machinery > assumes that each observer is orthogonal to others in its side > effects; what if this assumption doesn't hold? Yes, this is a very real problem. -- Daniel Jacobowitz