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