From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19361 invoked by alias); 5 Nov 2004 16:52:57 -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 19350 invoked from network); 5 Nov 2004 16:52:56 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 5 Nov 2004 16:52:56 -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 iA5GqmZM006387 for ; Fri, 5 Nov 2004 11:52:56 -0500 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iA5Gqjr32141; Fri, 5 Nov 2004 11:52:45 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id ED38E129D8C; Fri, 5 Nov 2004 11:52:28 -0500 (EST) Message-ID: <418BAFC9.6050705@gnu.org> Date: Fri, 05 Nov 2004 16:52:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Jeff Johnston , Eli Zaretskii , gdb-patches@sources.redhat.com Subject: Re: [RFA]: Watchpoints per thread patch 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> In-Reply-To: <20041105044917.GA13554@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00080.txt.bz2 Daniel Jacobowitz wrote: > On Thu, Nov 04, 2004 at 01:25:32PM -0500, Jeff Johnston wrote: > >>Daniel, I have moved the observer notification to add_thread as suggested. >>To do this, I had to move a few things in attach_thread. As well, I had to >>add another part of my full patch in because the ptid that add_thread knows >>about is in the wrong format (pid, 0, tid). The low-level insert >>watchpoint code needs the lwp so I have added in my target_get_lwp change. >>I realize you have plans to change how the ptid is kept, but until that is >>fleshed out, this change is required. I used a call-back to allow >>breakpoint.c which knows how to handle watchpoints to communicate with the >>low-level linux code that knows how to insert/remove a watchpoint. > > > 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? > 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. > The observer could move back to thread-db, but as Andrew keeps > reminding me, there are situations where we could take advantage of > thread-db for things like core files. This is a target stack activity; > I think we need to find a way to do it without violating the > abstraction of the target stack. There are two concurrency abstractions: - light-weight-processes system level - threads user level burried in the target stack, here the code is manipulating the former, thread-db manipulates the latter. That the abstractions are not clearly separated is a design flaw, but not one we're going to immediatly fix here. Andrew