This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
protocol spec
- To: gdb at sourceware dot cygnus dot com
- Subject: protocol spec
- From: Quality Quorum <qqi at world dot std dot com>
- Date: Sun, 19 Dec 1999 20:09:18 -0500 (EST)
Hi,
I made another look at the threads. It seems like search is still on :).
For example, I found yet another thread related query 'qfThreadInfo'
and 'qsThreadInfo' (which do not support 64-bit thread ids among
other things).
IMHO, we have to resolve just a few key issues here one way or other,
before piling new operations into remote protocol.
1. Do we want the remote to support per thread software breakpoints ?
Pro: It is done automatically for Linux-threads like environment
where each thread has its own text segment.
It will speed up debugging significantly.
Con: It would require some changes to be made both to
protocol and stub implementations with negative impact on
backward compatibility.
It will require some resources on the remote to maintain
a list of breakpoints with per thread assignments. So, we
have to define required size of the thing.
There are targets which do not have any intellect (e.g.
ICEs) which will require support on gdb side anyway.
My opinion: simplicity + compatibility wins - no per thread breakpoint
support. If gdbserver had different set of requirements,
it can support a different set of operations.
2. Do we want a remote to support per thread continue, step etc ?
Pro: It is done automatically for Linux-threads like environment
where each thread has its own text segment.
Con: Embedded system can have only one outstanding event with
only one thread involved a time, this is the only thread which
could be continued/stepped etc.
It would require some changes to be made both to
protocol and stub implementation with negative impact on
backward compatibility.
It will require some resources on the remote to maintain
a list of breakpoints with per thread assignments. So, we
have to define required size of the thing.
There are targets who do not have any intellect (e.g.
ICEs) which will require support on gdb side anyway.
My opinion: simplicity + compatibility wins - no per thread execution
support. If gdbserver had different set of requirements,
it can support a different set of operations.
3. Do we want to preserve existing ways of reporting thread list,
parameters and status ?
My opinion: simplicity + compatibility wins - existing packet
formats are good enough.
I got some more gotcha's analyzing the code:
1. 'Hc-1' is nothing else than an obsolete form of 'qC' and returned value
is always ignored by remote.c. It seems like this anachronism has to
be removed.
2. Limit on 31-bit pid values is internal to gdb for years to come
and until this happen, thread ids have to be < 0x80000000.
So, I had updated protocol specs accordingly and it seems like it is
quite implementable now.
I put new version at the usual place:
http://www.std.com/qqi/ftp/protocol.txt
ftp://www.std.com/Newbury/qqi/protocol.txt
Below is the summary of changes:
Expanded description of stub operating environment
Fixed thread description
Fixed signal range
Split thread support into thread information and thread control
Resurrected address part of continue and step signals, due to popular
demand
Added description of 'Z' and 'z' requests
Added section on gdb side (self-) configuration.
I updated rproxy and put it on the net:
http://www.std.com/qqi/labslave/rproxy.html
ftp://www.std.com/Newbury/qqi/rproxy-0.3.tar.gz
Thanks,
Aleksey