protocol spec

[Quality Quorum <qqi at world dot std dot com>]

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