This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: protoc spec


>>>>> "Quality" == Quality Quorum <qqi@world.std.com> writes:
Quality> I have updated GDB remote protocol specs with a few things
Quality> which are making it possible to do real develpment on its
Quality> base. Latest spec is attached to this mail, also I put it on
Quality> the net:

Quality> http://www.std.com/qqi/ftp/protocol.txt
Quality> ftp://www.std.com/Newbury/qqi/protocol.txt

Thanks for including your spec in this message.  I had all the best
intentions to review the 0.1 version of the spec, but never had the
opportunity to got to the website.

Quality> Also, after 7 years of heavy involvment with network protocol
Quality> development I am kind of attached to internet-drafts and
Quality> RFCs.  Does it seem as a good idea to publish final spec as
Quality> RFC ?  It seems to me that applicaton management area of IETF
Quality> would provide a very good review at least. At the same time
Quality> it introduces noticeable delays into process. So, I am not
Quality> quite sure.

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.  


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.

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.

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.

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.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]