memory verify

[J.T. Conklin]

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

        --jtc

-- 
J.T. Conklin
RedBack Networks