[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]