RE: memory verify

["Brown, Rodney" <rodneybrown at pmsc dot com>]

Title: RE: memory verify

The loop unrolled CRC-32 used in the info-zip tools (with a bit of extra
optimization) is 259 bytes i386 text space - but needs a 4*256 byte array.
Assuming that ultimate speed in CRC calculation isn't needed in the stub
then a nibble at a time varient - without loop unrolling should be possible
in < 259 bytes with a 4*16 = 64 byte array.
It should be possible to provide a CRC-32 in < 300 bytes (i386), if that
is strong enough.
Having just had a quick look at rsync, an MD4 checksum is being used - a cryptographic digest isn't it? If the rolling rsync checksum calculation

is small enough & you replaced the MD4 checksum with one or two 32-bit
CRC calculations you'd be able to do almost as well as with the MD4
checksum - but without the anti-tampering guarantees.
Note that adding another 32-bit CRC polynomial should only cost another
64 bytes of array or so.

-----Original Message-----
From: Andrew Cagney [mailto:ac131313@cygnus.com]
Sent: Wednesday, 1 December 1999 19:57
To: Brown, Rodney
Cc: 'gdb@sourceware.cygnus.com'
Subject: Re: memory verify

> "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