This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: memory verify
- To: "Brown, Rodney" <rodneybrown at pmsc dot com>
- Subject: Re: memory verify
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 01 Dec 1999 19:56:36 +1100
- CC: "'gdb at sourceware dot cygnus dot com'" <gdb at sourceware dot cygnus dot com>
- Organization: Cygnus Solutions
- References: <9150F3E779F0D211BD370008C733141C38AA12@aus-msg-02.au.pmsc.com>
> "Brown, Rodney" wrote:
>
> Depending how capable the stubs are, you could look at using Andrew
> Tridgewell's
> rsync algorithms. I think that uses CRCs to locate differences in
> files on
> different boxes to generate a delta file to update the file on one.
> This could allow the first difference idiom when run over large memory
> areas,
> without having to transmit the area over the wire.
Yes, I've had that in the back of my mind. Several aspects of a typical
embedded target make it less general then one would hope:
o the typical target has a weak CRC
(This suggests that perhaphs the check should
have a requirement that it be ``strong''.
How strong is an interesting question.
o rcync's performance depends heavily on the
stream nature of its remote connection.
The typical target uses an RPC like mechanism.
GDB's remote protocol is especially bad. The
overhead of requesting CRC's could quickly
mitigate any savings in avoiding downloads.
o remote targets are small and dumb with all the
the inteligence (?) and memory living in GDB.
Having said that, an embedded implementation of rsync would make for an
interesting performance boost when it came to re-loading memory. It
would definitly be a challenge to add an rsync session (it would be a
complex interaction than a simple exchange of packets) to GDB's remote
protocol.
enjoy,
Andrew