This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: memory verify
- To: jtc at redback dot com
- Subject: Re: memory verify
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 01 Dec 1999 12:25:12 +1100
- CC: gdb at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <5memd74iem.fsf@jtc.redbacknetworks.com>
"J.T. Conklin" wrote:
> We need a target primitive for doing memory verifies. There are three
> mechanisms that I can think of that can be used for this. Download a
> chunk of memory and an address and have the target determine whether
> they are the same; upload a chunk of memory at an address and have GDB
> perform the comparison; and perform a CRC or strong hash function on
> both the host and the target and compare the results.
>
> The second can be trivially implemented using the target vector's
> memory read function. However verify performance can be improved
> if the target supplies either a compare memory or checksum command.
>
> I propose the following new verify primitive:
>
> /* Verify that memory at GDB address MYADDR and target address
> MEMADDR are identical. This can be done by downloading the
> memory region to the target and having it do the comparison;
> uploading the memory region to GDB and having it do the
> comparision; using a checksum, cyclic redundency check, or
> cryptographic hash function; etc.
>
> Return value, N, is one of the following:
>
> 0 - memory region is not identical.
>
> 1 - memory region is identical. */
>
> int (*to_verify_memory) (CORE_ADDR memaddr, char *myaddr, int len);
>
> If the target cannot handle a memory region of that SIZE, the function
> is responsible for breaking it up into chunks.
Yes it's needed. It will allow me to eliminate a few more FIXME's :-).
Several thoughts:
I suspect that something like ``compare'' would convey a clearer meaning
than ``verify''. Verify makes me think of a 20 line assembler program
squeezed into a rom that verifies that memory is working :-)
Rather than to_XXX_memory() handling broken transfers, I'd prefer it if
the primitive returned the number of bytes matched by a single chunk.
That keeps the primative simple. It would also be consistent with
->to_xfer_memory(). A value <=0 would indicate no match (exactly what
zero means, given the spec for to_xfer_memory(), is ``left as an
exercise for the reader'' ;-)
A wrapper function could then provide the semantics you're looking for.
What should the target do if it isn't able to provide a more efficient
compare mechanism? My guess is leave the entry empty so that the higher
level code is able to differentiate between an efficient target memory
compare and a brutal memory read/compare. That would suggest
target_XXX_memory_p() and target_XXX_memory().
enjoy,
Andrew