Debugger under Solaris

[Robert Lunnon]

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

Any volunteers ?

[David Laight]

On Sat, Jun 11, 2005 at 09:17:09AM +1000, Robert Lunnon wrote:
> 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

I think you will find that solaris uses kernel LWPs for threads.
If you give ps the correct incantation it wil show them.

David

[Robert Lunnon]

On Saturday 11 June 2005 19:46, David Laight wrote:
> On Sat, Jun 11, 2005 at 09:17:09AM +1000, Robert Lunnon wrote:
> > 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
>
> I think you will find that solaris uses kernel LWPs for threads.
> If you give ps the correct incantation it wil show them.
>
> David

My Solaris implementation (which is the only one out there at the moment) uses 
bound threads, the lwp implementation no longer works. It doesn't matter 
really, the lwps share a common pid whereas under linux, I understand they do 
not, so ptrace under linux should be able to work on threads where ptrace 
under Solaris  definitely cannot.

Ptrace is going away under solaris anyway, so I will need the debugger code 
for the future anyway.

Bob

[Alexandre Julliard]

Robert Lunnon  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.

[Robert Lunnon]

On Sunday 12 June 2005 18:47, Alexandre Julliard wrote:
> Robert Lunnon  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