This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]