Re: protoc spec

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

On 16 Dec 1999, J.T. Conklin wrote:

> Unlike a RFC, the RDP specification (even your improved version) does
> not contain enough information to write a debug agent from scratch.
> For example, the order of registers in the byte arrays used by the
> register read and register write commands is not fixed.  In fact, 
> it varies from port to port for the same CPU.  

Yes, it seems like you are right.

> 
> 
> Quality> o Changes to version 0.2
> Quality>
> Quality>    Added section on backward comaptibility.
> Quality>
> Quality>    Added 'interrupt'.
> 
> The word 'interrupt' has many interpretations.  When I think of
> interrupts, I think of hardware interrupts; while in this document it
> appears to refer to the ^C or BREAK used to halt the target.  Perhaps
> a better word can be found to describe this.

Will  'stop' be a better term ?

> Quality> o Changes to version 0.1
> Quality>
> Quality>    Low case hex encoding is mandatory for byte arrays.
> 
> I have doubts whether this is safe.  Although GDB and the example
> stubs distributed with GDB uses lower case hex characters, there have
> never been any restriction on hex digits.  An independently developed
> stub could use upper case.

This stub will be useless, GDB will not be able to read memory from
this stub. So, it is indeed a hard requirement. 

> 
> Quality>    Dropped 'FromAddr' from all continue and step requests -
> Quality>    it is not used by gdb anyway.
> 
> Is there any reason to do this?  The jump command sets the PC to a new
> address and then continues execution.  This is currently done as a reg
> write and a continue, but there is nothing that would prevent us from
> recognizing this sequence and using an address.  This would avoid the
> latency required for two commands, which could be an issue for some
> target environments.
> 
> There is also no reason why the RDP couldn't be used with another
> front end other than GDB --- Perhaps something that looks very much
> like a traditional ROM monitor.  In this sort of environment, a step @
> address and continue @ address featurs would be quite useful.

I beleive that if people using gdb (and there is a huge variety here),
did not find a minute to implment this feature on the gdb side
in all these years there is no point in implementing it at all.
However, this one could be easily reversed.


> Quality> 2. Remote GDB Stub Execution Environment
> Quality>
> Quality> Let us start from describing environment where remote stub is
> Quality> executed.  It is generally assumed that stub is executed in
> Quality> exception handling context with all other processes in the
> Quality> system under debugging (the system) frozen until stub
> Quality> receives command from gdb to continue.  Even if the stub
> Quality> supports per thread breakpoints, all threads of execution in
> Quality> the system are frozen when breakpoint/exception is taken by
> Quality> any one of them
> 
> Do we really want to specify a particular implementation like this?
> It seems to preclude alternate implementations.  For example, a 
> debug agent running as one thread in the target system.

It is required by a sematics of thread support requests: it
(silently) implies that threads should not change while debugger
exchanges thread information with a stub.

It is quite possible that 'system under debugging' is a process
on the remote system, however, all threads of this process 
have to be frozen when stub code is activated by exception,
breakpoint or interrupt command, this is another hard 
reuirement.

 
>         --jtc

Thanks,

Aleksey