From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30589 invoked by alias); 13 Jan 2005 19:22: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 30494 invoked from network); 13 Jan 2005 19:22:51 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 13 Jan 2005 19:22:51 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j0DJMpcI013085 for ; Thu, 13 Jan 2005 14:22:51 -0500 Received: from pobox.toronto.redhat.com (pobox.toronto.redhat.com [172.16.14.4]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j0DJMkr17220; Thu, 13 Jan 2005 14:22:46 -0500 Received: from touchme.toronto.redhat.com (IDENT:postfix@touchme.toronto.redhat.com [172.16.14.9]) by pobox.toronto.redhat.com (8.12.8/8.12.8) with ESMTP id j0DJMjoS032150; Thu, 13 Jan 2005 14:22:45 -0500 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 82139800001; Thu, 13 Jan 2005 14:22:45 -0500 (EST) Message-ID: <41E6CA85.5090407@redhat.com> Date: Thu, 13 Jan 2005 19:22:00 -0000 From: Jeff Johnston User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFA]: Modified Watchthreads Patch 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> In-Reply-To: <20041211173256.GA15506@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-01/txt/msg00106.txt.bz2 Daniel Jacobowitz wrote: > 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. > Sorry, I should have responded to this ages ago. I prefer #2. I assume the hook resides in the target vector or have you got some other idea in mind? -- Jeff J.