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


>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> I suspect that something like ``compare'' would convey a
Andrew> clearer meaning than ``verify''.  Verify makes me think of a
Andrew> 20 line assembler program squeezed into a rom that verifies
Andrew> that memory is working :-)

Andrew> Rather than to_XXX_memory() handling broken transfers, I'd
Andrew> prefer it if the primitive returned the number of bytes
Andrew> matched by a single chunk.  That keeps the primative simple.
Andrew> It would also be consistent with to_xfer_memory().  A value
Andrew> <=0 would indicate no match (exactly what zero means, given
Andrew> the spec for to_xfer_memory(), is ``left as an exercise for
Andrew> the reader'' ;-) A wrapper function could then provide the
Andrew> semantics you're looking for.

This is possible if either the host or the target are comparing the
values, but when we're comparing checksums or CRCs all we know that
some data somewhere is different.  In that case, what value should
be returned?  Or are you suggesting the length is only interesting
for successful compares of a chunk so we'll know where to start the
next chunk?

Andrew> What should the target do if it isn't able to provide a more
Andrew> efficient compare mechanism?  My guess is leave the entry
Andrew> empty so that the higher level code is able to differentiate
Andrew> between an efficient target memory compare and a brutal memory
Andrew> read/compare.  That would suggest target_XXX_memory_p() and
Andrew> target_XXX_memory().

But is there a reason for higher level code to care how the compare is
implemented?  We could have target_XXX_memory check current_target->
to_XXX_memory --- if it's NULL, call that function otherwise a generic
implementation would be used.

        --jtc

-- 
J.T. Conklin
RedBack Networks

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