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

Does it matter?

I can see several specifications:

	>0	Indicates the size of a matching chunk
	=0	data mis-match if errno==0

or	>0	Indicates the size of the matching chunk
	=	data mis match if errno=0
	<0	data mis-match somewhere beyond |<0|

or	>0	number bytes succesffuly compared
		(there might be a data mismatch beyond this).
	=0	data mis-match

The middle spec provides the most information.  Only question is would
it be useful?  I don't know.
The program download code may be able to exploit this knowldege.

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

Typically, yes.  I can think of two cases:

	o	a weak/broken CRC algorithm
		which the user doesn't like.

	o	Internal operations such as
		program download that would
		exploit the CRC when available.
		(ex program load could run the crc
		before downloading each section.
		This could cleanup the compare
		sections command.).

enjoy,
	Andrew

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