From owner-p4-projects@FreeBSD.ORG Thu Jul 1 01:45:51 2004 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 0741A16A4D0; Thu, 1 Jul 2004 01:45:49 +0000 (GMT) Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8703816A4CE; Thu, 1 Jul 2004 01:45:49 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id D09B843D41; Thu, 1 Jul 2004 01:45:48 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp50.pn.xcllnt.net (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.12.11/8.12.11) with ESMTP id i611jShW031551; Wed, 30 Jun 2004 18:45:28 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp50.pn.xcllnt.net (localhost [127.0.0.1]) i611jSb1044512; Wed, 30 Jun 2004 18:45:28 -0700 (PDT) (envelope-from marcel@dhcp50.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp50.pn.xcllnt.net (8.12.11/8.12.11/Submit) id i611jSni044511; Wed, 30 Jun 2004 18:45:28 -0700 (PDT) (envelope-from marcel) Date: Wed, 30 Jun 2004 18:45:28 -0700 From: Marcel Moolenaar To: David Xu Message-ID: <20040701014528.GB44343@dhcp50.pn.xcllnt.net> References: <200406302305.i5UN5Dtj055376@repoman.freebsd.org> <20040701000327.GA44174@dhcp50.pn.xcllnt.net> <40E365CE.8070508@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40E365CE.8070508@freebsd.org> User-Agent: Mutt/1.4.2.1i cc: Perforce Change Reviews Subject: Re: PERFORCE change 56172 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2004 01:45:51 -0000 On Thu, Jul 01, 2004 at 09:15:58AM +0800, David Xu wrote: > >> > >> Let ptrace deal with lwpid as pid. remove ttrace. > > > > > >Excellent! Any complications with using ptrace(2) or did it all > >fall out naturally as I hoped? > > > > I think there is not important problem within this change, current > if I PT_GETREGS with a pid but not lwpid, I just use first thread > in the proc, this needs to be studied further whether we should reject > the call for threaded process. also I allow PT_ATTACH etcs to use > lwpid. Very nice. I think we're getting in a pretty good shape. What do you think? I plan to commit the libthr changes I in a couple of days. If we're confident that the ptrace(2) change is a keeper, we can also commit it. Then it's just a matter of finishing libthread_db. You already have libpthread mostly covered and I should have libthr and libc_r done soon as well.. > OK, feel free to do. I only have trouble with gdb_proc_service.h, gdb > it defines proc service function prototypes and some other types. but > libthread_db needs a proc_service.h, I don't want to let libthread_db > depend on gdb_proc_service.h, so we need to keep our proc_service.h > consistent with gdb, or we don't use gdb's proc_service.c at all, we > write our version of proc_service.c as solaris thread db did. I embedded the proc_service interface in fbsd-thread.c. I don't use the existing code, because it has Linuxisms and ugliness, not to mention that it's more efficient to not use it (see below). > However, in my experience, gdb proc service works well. > I only use it when I need to retrieve lwp's registers, the gdb's proc > service really doing nothing, it just redirect all requests to > current target, I implement fbsd_fetch/store_lwp_registers > in my freebsd-thread.c, they will be called by gdb proc service, > the code path in my libthread_db and freebsd-thread.c looks like > following: > > libthread_db -> ps_lgetregs -> target_fetch_registers > -> fbsd_thread_fetch_registers -> fbsd_fetch_lwp_registers -> > -> ptrace(lwp) In my code it's: libthread_db -> ps_lgetregs -> target_fetch_registers -> ptrace(lwp). This is because ps_lgetregs is part of the thread target and thus knows to go directly to the target that's underneath the thread target and also does the necessary rewrite of the PTID so that the lower level targets operate on the LWPID without knowing about it. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net