This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Remote protocol tune up...
- To: William Gatliff <gatliff at haulpak dot com>
- Subject: Re: Remote protocol tune up...
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 15 Oct 1999 10:03:54 +1000
- CC: GDB Discussion <gdb at sourceware dot cygnus dot com>
- Organization: Cygnus Solutions
- References: <3805B369.464A948C@cygnus.com> <3805CD64.3A2AA33D@haulpak.com>
William Gatliff wrote:
>
> Andrew:
>
> > comments, complaints?
>
> Not sure I follow everything you suggested, but I'm no gdb-internals guru
> by far...
>
> Just make sure the maximum packet size is clearly and easily
> configurable--- lots of targets don't even have a few hundred bytes of
> contiguous memory in which to store an incoming gdb packet...
Yes, definitly. That is last thing on my mind :-)
At present the remote protocol determines the size of the largest packet
based on MIN(sizeof registers_packet, ``remote packet-size - a small
number''). That will remain the default behavour.
I'm looking to:
o maximize the size of that packet (within
the bounds imposed by the remote target).
What happens at present is that generic_load
requests N transfers of 256 bytes say, but then
a lower layer (remote_write_bytes()) breaks that
256 byte chunk into two packets of ~240 and ~16
bytes :-(.
The proposed change will see remote_write_bytes()
transfer a 240 byte packet and then return to
generic_load() which can then top things up and
issue a brand new transfer request.
O allow the user to maximize the size of each
packet (almost) lifting all the arbitrary bounds.
When the target's buffer is huge and the bandwidth
almost infinite there is little point in transfering
things in little 256 byte chunks :-)
enjoy,
Andrew