RE: Adjusting my debugger to work with NPTL

It's a bit of an info overload, but I used the strace output to see a 
lot of the details on how the kernel debug interface works.

BTW, the tid is a new concept for identifying individual threads in a
process group. The gettid() and tkill(tid, sig) APIs were added to
handle
them, along with _WCLONE for wait and wait4. You will see this in the 
strace output for a gdb session.

Thanks,
Dave Howell  

These are my opinions and not official opinions of Intel Corp.

David Howell
Intel Corporation
Telco Server Development
Server Products Division
Voice: (803) 461-6112  Fax: (803) 461-6292

Intel Corporation
Columbia Design Center, CBA-2
250 Berryhill Road, Suite 100
Columbia, SC 29210

[email protected]


-----Original Message-----
From: Norman Black [mailto:[email protected]] 
Sent: Friday, May 02, 2003 12:14 PM
To: [email protected]
Subject: Re: Adjusting my debugger to work with NPTL

Thanks for taking the time to respond to my query.

> > My specific needs/questions are how to.
> > 1) stop and continue an individual thread. previously I used SIGSTOP
and
> > SIGCONT with kill.
>
> SIGSTOP will stop all threads in the task.  SIGCONT will resume all
threads
> in the task.  (This is true whether kill or tkill is used.)  You can
resume
> individual (traced) threads with PTRACE_CONT.  There isn't a way to
stop a
> single thread other than to stop all threads and then PTRACE_CONT a
subset.

SIGSTOP and SIGCONT pass to kill I understand in the new signaling
context.
How can PTRACE_CONT continue a single thread since ptrace wants a pid
and all threads now have the same pid.

What is tkill. Do I need it? I found no tkill API in the header files.
It appears to only be a system call. No docs.

> There isn't a way to stop a
> single thread other than to stop all threads and then PTRACE_CONT a
subset.

This is bogus and a step backwards. Is this a temporary omission?

> > 2) How are thread debug events received since wait returns "process"
> > signals. previously waitpid (possibly using __WCLONE) resulting in a
> > SIGTRAP was the catchall.
>
> You PTRACE_ATTACH to each individual thread PID, and then wait reports
> signal stops for each different thread as it stops.

thread PID?. I thought all threads had the same pid in NPTL? ptrace
wants pids and not tids, right?

How can wait return for a thread since all threads have the same PID?
Has wait been extended to return TIDs. I have been using waitpid, so do
I need to switch to using wait.

> Right now the best place to see what to do is in the gdb code.  I
think the
> changes are getting merged into mainline development gdb now.  Or look
at
> the sources of the the Red Hat gdb rpms in RHL9 or Rawhide.

I figured as much but I *absolutely* hate the gdb/gnu tools programming
style/structure. I would rather have a root canal. I have found reading
kernel and GTK+ code far easier. I should mention that I am not a C
programmer. My companies compiler is Modula-2.

> The kernel ptrace support for handling multiple threads is barely
> sufficient, but not as good as it should be.  This will probably get
> improved in 2.5 one of these days.

It seems RH maybe jumped the gun by putting NPTL in RH9. From an
application point of view things seem fine, but the development side
sounds like it still is in transition.

There is no reason Linux should take a second seat to Solaris and
Windows. Both platforms which I have developed debugger for, and they
have complete debugger APIs.

Best Regards,
Norman Black
Stony Brook Software




-- 
Phil-list mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/phil-list