GDB and multithreaded gdbserver

GDB and multithreaded gdbserver

[John Whitney]

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

Re: GDB and multithreaded gdbserver

[Daniel Jacobowitz]

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