Date: Thu, 01 Jul 2004 10:27:19 +0800 From: David Xu <davidxu@freebsd.org> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 56172 for review Message-ID: <40E37687.4030903@freebsd.org> In-Reply-To: <20040701014528.GB44343@dhcp50.pn.xcllnt.net> References: <20040701014528.GB44343@dhcp50.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40E37687.4030903>