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

Re: Adjusting my debugger to work with NPTL

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

> 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.  You have to attach
each thread, the ptrace-attachedness is not inherited.  If you are using
libthread_db and request thread-creation event reporting, then you can
attach to each new thread when you get the event.  This is what gdb does.

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.

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.

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