Debugger under Solaris

Robert Lunnon bobl at optushome.com.au
Tue Jun 14 06:11:47 CDT 2005


On Sunday 12 June 2005 18:47, Alexandre Julliard wrote:
> Robert Lunnon <bobl at optushome.com.au> writes:
> > I need some help to implement the debugger under Solaris. In particular I
> > need help with how ptrace interacts with the threading model under Linux
> > which I understand uses processes for threads. Since Solaris has user
> > mode threads, stopping a pid stops all the threads in the debugee which
> > used to deadlock the debugger. This suggests I need to operate on threads
> > within processes rather than the processes themselves. This is possible
> > with a few IPC tricks, but I need to understand the semantics
>
> Stopping the whole process with ptrace is not a problem, that's how
> Linux NPTL behaves too. What you really need is the ability to change
> registers and send signals to a specific thread, which requires the
> kernel to at least know something about the individual threads.

Done, I think I now have a workable debugger interface based on procfs, 
including a simulation of wait4 using the poll syscall.

I get some odd warnings though

EG, in function handle_child_status I have the following code

TPTRACE( PTRACE_SINGLESTEP, pid,get_ptrace_tid(thread), (caddr_t)1, sig );

which would have replaced 
ptrace( PTRACE_SINGLESTEP, pid, (caddr_t)1, sig );

The sun equivalent I have written has a template
long sunptrace (int request, pid_t pid, lwpid_t lwp, void *addr, void *data);

(The MACRO TPTRACE is a way to selectively choose between ptrace 
implementations at compile time without lots of #ifdefs)

I get warnings from the last argument 
passing arg 5 of `sunptrace' makes pointer from integer without a cast 


Problem is I don't see what these arguments do, neither the linux nor Solaris 
ptrace pages refer to arg 3 or 4 of ptrace (ie arg 4 and 5 of sunptrcae) 
being required for PTRACE_SINGLESTEP or PTRACE_CONT shouldn't these args be 
either omitted or cast properly. Perhaps I'm missing something here ?

Later this occurs again in write_thread_int, and read_thread_int, the data arg 
is integral type not a pointer per the linux man page (well the one I got 
from google anyway)
Bob





More information about the wine-devel mailing list