From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15498 invoked by alias); 11 Feb 2005 17:11:43 -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 15388 invoked from network); 11 Feb 2005 17:11:32 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 11 Feb 2005 17:11:32 -0000 Received: from zaretski (tony04-57-217.inter.net.il [80.230.57.217]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id ANG26606 (AUTH halo1); Fri, 11 Feb 2005 19:10:30 +0200 (IST) Date: Fri, 11 Feb 2005 18:18:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-ID: <01c5105b$Blat.v2.4$bb9e28a0@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: <20050210195838.GA12332@nevyn.them.org> (message from Daniel Jacobowitz on Thu, 10 Feb 2005 14:58:39 -0500) Subject: Re: [RFA]: Modified Watchthreads Patch Reply-to: Eli Zaretskii References: <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> <41E6CA85.5090407@redhat.com> <20050210195838.GA12332@nevyn.them.org> X-SW-Source: 2005-02/txt/msg00106.txt.bz2 > Date: Thu, 10 Feb 2005 14:58:39 -0500 > From: Daniel Jacobowitz > Cc: Eli Zaretskii , gdb-patches@sources.redhat.com > > > >>>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? > > I believe I was waiting for further feedback from Eli on the role of > observers within GDB. 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?