* Re: GDB and multithreaded gdbserver
2002-04-29 7:29 GDB and multithreaded gdbserver John Whitney
@ 2002-04-29 8:32 ` Daniel Jacobowitz
0 siblings, 0 replies; 2+ messages in thread
From: Daniel Jacobowitz @ 2002-04-29 8:32 UTC (permalink / raw)
To: John Whitney; +Cc: gdb
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
^ permalink raw reply [flat|nested] 2+ messages in thread