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