Re: memory verify

[Andrew Cagney <ac131313 at cygnus dot com>]

"J.T. Conklin" wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> >> 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.
> 
> Andrew> Typically, yes.  I can think of two cases:
> Andrew>
> Andrew> o a weak/broken CRC algorithm
> Andrew>   which the user doesn't like.
> Andrew>
> Andrew> o Internal operations such as
> Andrew>   program download that would exploit the CRC
> Andrew>   when available.  (ex program load could run
> Andrew>   the crc before downloading each section.  This
> Andrew>   could cleanup the compare sections command.).
> 
> I don't think the existance of a to_XXX_memory() vector function is
> enough of a hint for upper layers of GDB to decide whether to use it.
> For example, changing generic_load() to call to_XXX_memory() on each
> section to determine whether it is already loaded makes a lot of sense
> with targets with CRC-like verification.  Those that implement it with
> a 'srecord verify'-like mechanism would lose (some ROM monitors have a
> command where a srecord stream is compared with the contents of memory
> instead of replacing the contents).  But perhaps this is an argument
> against using that kind of implementation.  Thoughts?

Bleuk :-)

That suggests one requirement on that method is that it be significantly
faster than a simple memory read :-)

	Andrew