From owner-p4-projects@FreeBSD.ORG Thu Jul 1 02:24:21 2004 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 3E21616A4D0; Thu, 1 Jul 2004 02:24:21 +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 D84AA16A4CE for ; Thu, 1 Jul 2004 02:24:20 +0000 (GMT) Received: from exchhz01.viatech.com.cn (ip-40-162-97-218.anlai.com [218.97.162.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9145D43D2D for ; Thu, 1 Jul 2004 02:24:18 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freebsd.org (DAVIDWNT [10.4.1.99]) by exchhz01.viatech.com.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id NVXA685Q; Thu, 1 Jul 2004 10:23:51 +0800 Message-ID: <40E37687.4030903@freebsd.org> Date: Thu, 01 Jul 2004 10:27:19 +0800 From: David Xu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030723 Thunderbird/0.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcel Moolenaar References: <20040701014528.GB44343@dhcp50.pn.xcllnt.net> In-Reply-To: <20040701014528.GB44343@dhcp50.pn.xcllnt.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 02:24:21 -0000 Marcel Moolenaar wrote: > 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? > Yes, we are. > 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.. > Yes, I think libthr needs to use lwpid. For ptrace commit, will you do it or let me do ? I added a PT_CLEARSTEP command, because I think PT_CONTINUE is not sufficient, sometimes, you want to clear single step for a thread, but without resuming the process before other things are done, also I introduced a PT_GETXTHREAD, it is the thread reporting SIGTRAP to debugger, debugger will use the thread as current thread, and dump stack backtrace when process stops. other commands, PT_GETNUMTHRS, PT_GETTHRLIST are not important, and I have never used them yet. > >>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). > > Agree. >>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. > Yes, if proc service is implemented fbsd-threads.c, then some extra steps can be eliminated.