This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: GDB-Protocol: Version/Protocol packet
- To: Stan Shebs <shebs@cygnus.com>
- Subject: Re: GDB-Protocol: Version/Protocol packet
- From: Andrew Cagney <ac131313@cygnus.com>
- Date: Thu, 17 Jun 1999 10:58:27 +1000
- CC: gdb@sourceware.cygnus.com
- Organization: Cygnus Solutions
- References: <199906170043.RAA18788@andros.cygnus.com>
Stan Shebs wrote:
>
> From: Andrew Cagney <ac131313@cygnus.com>
> Date: Thu, 17 Jun 1999 10:29:41 +1000
>
> As a starting point, I'd like to put forward:
>
> <- qVersion
> -> { <prefix><version> }
>
> Hmmm. The details seem overly complicated, which is bad for a
> target-side agent that ought to be smaller than it is now. The
> protocol already has a provision for unrecognized packets, namely that
> the stub should return an empty response. And what would GDB do with
> a version number? If it does nothing, then why bother, and if it does
> something, then it's not optional, every target stub has to do the
> right thing.
While the current non-response schema works well for the case of an
unsupported packet it isn't so good at identifying a target that has
support for non-aproved packets. In addition it doesn't address the
looming problem of actually running out of packet prefixes.
With respect to the version number/response GDB could do a lot with it.
During the initial connection it would be able to configure its self
cleanly to handle all specified packets.
BTW, another possability for the packet would be:
<- !
-> B2...
ie the ``extended-remote'' packet returned additional information. That
would make the implementation very easy:
case '!':
extended = 1;
putpkg ("....");
Hmm this raises a second issue...
Andrew