This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: memory verify
>>>>> "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