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: Standard GDB Remote Protocol


"J.T. Conklin" wrote:
> 
> Steven> 8/7 Bit protocol.
> Steven> With the documentation of RAW Binary transfers, the protocol moves from
> Steven> being a strictly 7 bit affair into being a 8 bit capable protocol. If
> Steven> this is so, then shouldn't all the restrictions that are placed from the
> Steven> 7 bit protocol days be lifted to take advantage of the capabilities of
> Steven> an 8 bit message stream. (RLE limitations, for example). Would anyone
> Steven> seriously be using a computer that had a 7 bit limitation anymore
> Steven> anyway? (At least a computer that would run GDB with remote debugging).
> 
> I'm more concerned with the other side than the GDB side.  I can
> imagine a target that could only reasonably support a 7 bit channel.

Yes, it's optional for that reason (and yes, the spec should clarify
that :-)

> Steven> Thoughts on consistency and future growth:
> Steven> Apply RLE as a feature of All messages. (Including binary messages, as
> Steven> these can probably benefit significantly from it).
> 
> Steven> Apply the Binary Escaping mechanism as a feature of the packet that is
> Steven> performed on all messages prior to transmission and immediately after
> Steven> reception. Define an exhaustive set of "Characters to be escaped".
> 
> Steven> Introduce message timing constraints.
> Steven> Properly define sequence-id and allow it to be used from GDB to make
> Steven> communications secure and reliable.
> 
> These are all great, but I'm not sure how much can been within the
> confines of the existing protocol.

As a vague suggestion of a ``five year'' gdb-protocol plan:

	v2.0:	Formalize the lower layers (transport, ...?)
		(Where's my AST networks book :-) and address
		issues such as reliability.

		The command set would remain the same - warts
		and all.

	v3.0:	Look at the actual gdb command set

If the two can be separated then, there is some hope of being able to
move forward.  As an incentive, the getpkt() and putpkt() functions and
several chunks of remote.c need a further rewrite any way.  They should
to be inverted so that they are based on an event model.  Clearly
separating the layers would help this.

The alternative, as always, is to start again from scratch.

	Andrew

(As for the mini-telnet, if someone would like to propose a decent
telnet extenstion to the protocol then, I'm all ears)

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