GDB and multithreaded gdbserver

["John Whitney" <john.whitney@timesys.com>]

Hello,

I am investigating writing a multithreaded gdbserver for linux (only,
because I am doing away with thread_db), and had some implementation/remote
protocol questions:

1. What is the algorithm for stepping/continuing threads?  It *appears* to
be something like the following:
When continuing a thread, continue ALL threads (and/or report interesting
signals stopping another thread already).  When stepping a thread, step ONLY
the current thread and don't report interesting signals on other threads
until switched to them or this thread is continued.  Is there any way to
step all (or some) threads at the same time?

2. I've seen some postings about not being able to report thread deaths, but
I haven't yet been able to determine if this is a thread_db limitation or a
protocol limitation.  If it is a thread_db limitation, what is the correct
procedure to report a thread death (a W status seems to be interpreted by
GDB as death of the inferior in general and causes it to stop debugging)?

3. What's the proper response to the qfThreadInfo request?  Based on
Subhashini's (I think?) gdbserver document, it looks like this should be
answered with an OK packet, and the server should expect a qsThreadInfo
request to actually retrieve this information.  However, using GDB5.1.1, I
never see a qsThreadInfo request, so I am assuming this is a design
suggestion and not the way it is currently implemented.  If that is indeed
the case, what IS the proper response to this packet?

4. I guess most importantly, is there a document describing the remote
protocol?  I've looked at the one referenced on Dan Kegel's site (Quality
Quorum's document), but it seems a bit out-of-date.  Some things I've
figured out by looking at remote.c in the GDB source, but that is a bit
cumbersome.

Thank you for any help,
John Whitney
john.whitney@timesys.com