PERFORCE change 56172 for review

[Marcel Moolenaar]

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 at xcllnt.net