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


"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

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