From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10915 invoked by alias); 11 Dec 2004 17:33:05 -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 10889 invoked from network); 11 Dec 2004 17:33:01 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 11 Dec 2004 17:33:01 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CdB72-00044V-GZ; Sat, 11 Dec 2004 12:32:56 -0500 Date: Sat, 11 Dec 2004 17:38: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: <20041211173256.GA15506@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> <20041211161136.GA13865@nevyn.them.org> <01c4dfa2$Blat.v2.2.2$486cc380@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4dfa2$Blat.v2.2.2$486cc380@zahav.net.il> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-12/txt/msg00306.txt.bz2 On Sat, Dec 11, 2004 at 06:54:53PM +0200, Eli Zaretskii wrote: > > Date: Sat, 11 Dec 2004 11:11:37 -0500 > > From: Daniel Jacobowitz > > Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com > > > > Are there really any current uses of observers which meet your > > definition above? > > I'm unsure which definition you refer to. Let me try to clarify then... this is what you said: > 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? 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!). I think this is a fine use of observers; one "module" of GDB wants to be notified when an event occurs in another. > > 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? > > Either one of them is better. Great! Jeff, Mark, do you have opinions on either (or other suggestions)? 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. In one case it would have to be documented in observers.texi and support functions would be autogenerated; in the other case it would probably be documented in comments, and bunch of support functions would have to be written by hand, instead of being generated by the observers shell script. -- Daniel Jacobowitz