Re: GDB and multithreaded gdbserver

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Apr 29, 2002 at 10:28:37AM -0400, John Whitney wrote:
> 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:

Before you go down this path, John, I should tell you that I've got the
work entirely finished now.  I have another couple days of legal
legwork, but I hope to be posting the code (or at least the first step,
which requires two small changes to the remote protocol) by the end of
the week.

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

Look at general_thread and cont_thread.  If cont_thread is 0, and a
step command is received, you step one thread and continue all the
others.  Single-stepping multiple threads in lockstep isn't supported,
but it's really not very useful... we'd need to extend the protocol
further to support that.

One of the protocol extensions I mentioned allows specifying -which-
thread to singlestep when cont_thread is 0.

> 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)?

In the context you've seen it mentioned, it is a limitation of a buggy
version of thread_db.  In glibc 2.2.x, this works fine, but isn't
especially necessary.  It is also a limitation of the remote protocol;
my other protocol extension was thread death notification :)

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

Not an OK, a single (or multiple) thread ID ('m' packet).  I just do
one instead of fitting as many in the buffer as possible, but I'll fix
that after it's merged; it's a minor performance improvement.

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

It's in the GDB Texinfo manual, node "Remote Serial Protocol".

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer