Subject: Re: ptrace(2) + nathanw_sa LWPs
To: Giles Lean <giles@nemeton.com.au>
From: Andrew Cagney <cagney@mac.com>
List: tech-kern
Date: 12/07/2001 22:39:22
> 
> Is it interesting to compare what other operating systems have done?
> HP-UX introduced ttrace(2) to overcome the limitations of ptrace(2)
> with multithreaded processes, and HP contributed changes to gdb to
> enable it to use ttrace(2).
> 
> http://docs.hp.com//hpux/onlinedocs/B2355-90682/00/02/219-con.html
> 
> I don't know how Solaris supports debugging multithreaded processes
> as its ptrace(2) manual page doesn't refer to threads at all.
> 
> http://docs.sun.com:80/ab2/coll.40.6/REFMAN2/@Ab2PageView/54414?Ab2Lang=C&Ab2Enc=iso-8859-1

The other source of info is current GDB sources.  Look at the 
src/gdb/*th*.c files.  They tend to include good commentry on what went 
wrong with the various thread models.

I would advice against making ptrace() state full - it will make 
debugging the debugger a right pain.

You should also review signal() and wait() as they, and ptrace() can end 
up with some pretty hairy interactions.

Finally, can I suggest the mailing list gdb@sources.redhat.com - I know 
people there will be willing to tell you their war stories.

	Andrew

PS: Having all threads stop is a very good first move.
PPS: I know zilch about debugging threads so please don't ask me :-)
PPPS: Sun has ``libthread_db''.