From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6395 invoked by alias); 5 Nov 2004 18:29:02 -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 6383 invoked from network); 5 Nov 2004 18:29:00 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 5 Nov 2004 18:29:00 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CQ8pO-0005vF-GM; Fri, 05 Nov 2004 13:28:50 -0500 Date: Fri, 05 Nov 2004 18:29:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Jeff Johnston , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFA]: Watchpoints per thread patch Message-ID: <20041105182850.GA22533@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Jeff Johnston , Eli Zaretskii , gdb-patches@sources.redhat.com References: <4175A9C9.8040300@redhat.com> <41769FF3.7010801@gnu.org> <20041020173035.GA26622@nevyn.them.org> <418022DE.204@redhat.com> <01c4bca9$Blat.v2.2.2$adcffb00@zahav.net.il> <418A741C.4080306@redhat.com> <20041105044917.GA13554@nevyn.them.org> <418BAFC9.6050705@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <418BAFC9.6050705@gnu.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00083.txt.bz2 On Fri, Nov 05, 2004 at 11:52:25AM -0500, Andrew Cagney wrote: > Daniel Jacobowitz wrote: > >I don't want to add target_get_lwp only to remove it a couple weeks > >later! I don't think this patch is appropriate for 6.3; for the > >mainline, we have plenty of time, so please wait a little longer. > > You're correct, it definitly isn't appropriate for 6.3. However, it is > appropriate for mainline. Lets get this patch off the table (and have > working watchpoints), that way we're in a position to better focus on > just the refactorings you talk of. Especially since, this work gives us > a working test case that we can refactor against. > > Sound reasonable? Andrew, I'm confused. Aren't you the maintainer who is historically most likely to jump on contributors for kludging around missing infrastructure? I think we should solve this correctly, not with (so far) two majorly incorrect hacks. And we've already got working watchpoints. This is for multi-threaded hardware watchpoints, which have never worked right in GDB and thus seem to me like a new feature. > >You were going to fix this bit. > > > >Also, I have been thinking about your approach. You are hooking native > >code in via an observer; observers bypass the target stack. It worked > >while you were only calling this observer from the GNU/Linux native > >support in thread-db.c. But now it will mess up if you use a native > >ia64 debugger connected to a remote target, in which case we should > >never enter the ia64-nat code - there's nothing to ptrace. > > Jeff, > > I'd use the cludge based on what is found in remote.c: > if (!current_target.to_shortname || > strcmp (current_target.to_shortname, "remote") != 0) > error ("command can only be used with remote target"); > we need to solve the problem daniel describes but that involves > structural change. There are plenty of other ways to solve this. This entire operation should go through the target stack. My cleanups, and yours, are bringing us to the day when target vector inheritance can be used for GNU/Linux; then we can do this properly. The precedent of using observers to support target-stack-specific code is a horrible one that we should avoid. Then targets which need this operation can supply a target_fixup_watchpoints_for_new_thread, and the observer can live in core code instead of each target. Doesn't that seem like a better solution? -- Daniel Jacobowitz