This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Remote protocol tune up...
"J.T. Conklin" wrote:
>
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> Andrew> * generic_load()
>
> Andrew> (Ignoring the bug fixes) This function will be changed to use
> Andrew> target_write_memory_partial(). This allows the code to
> Andrew> re-charge each transfer attempt to the maximum allowable
> Andrew> (according to the chunk size). The GENERIC_LOAD_CHUNK will
> Andrew> also be replaced by a run-time variable that even allows
> Andrew> chunking to be disabled. I'll also bump GENERIC_LOAD_CHUNK up
> Andrew> to 512 (2*512 + header/footer <= sizeof (udp packet)), any
> Andrew> bids for 1024?
>
> Umm, just how are you computing sizeof(udp packet)? I count 20 bytes
> for a IP packet without any options plus 8 for the UDP header for a
> zero length UDP packet. Not that this matters much...
I'm a computer scientist, I count in powers of two :-)
(The 2*512 is what the M packet does to 512 bytes of data. The X
packet's worse case is the same.
> A logical refinement of your proposal would be to do target write size
> discovery. Instead of having generic_load() attempt to write N bytes,
> target_write_memory() return an indication that M bytes were actually
> written, 're-chargeing' the transfer by adding N-M bytes of data, and
> then attempting to write an N byte buffer again; I believe it should
> drop back to using an M byte write.
Don't forget that the size of each write isn't predictable - an X packet
might need to expand one M byte chunk to 2*M bytes (everything escaped)
while the next goes straight through. You're never absolutly certain
how much will get transfered at each attempt :-)
The other obvious question would be: what is GENERIC_LOAD_CHUNK for? It
puts an absolute cap on the download chunk size. This (simplisticly)
ensures that a UI has a look in on the process so that it can detect
things like a request to abort the transfer.
enjoy,
Andrew