PERFORCE change 56172 for review

[David Xu]

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.