This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: deferred stores as a solution to store register api?
"J.T. Conklin" wrote:
> Andrew> I agree with your comment that the target api needs to be
> Andrew> extended so that high-gdb can tell low-gdb (target) that it is
> Andrew> performing a batched update and, as you suggest, something
> Andrew> like _defered_store() will make that more efficient. I just
> Andrew> also think we may need to add some extra code so that the
> Andrew> existing behavour (each command is atomic ???) is also
> Andrew> retained.
>
> The window where GDB holds state that the target does not would be
> tightened if we add a target_do_deferred_store() after commands have
> completed execution. Would this be enough?
That would do it but I don't know that such code should be telling the
target directly to push out those registers. Refering to that bad ascii
art:
High GDB
|
\|/
pseudo reg-nr
|
map pseudo <->
random cache
bytes
|
\|/
------------
| register |
| cache |
------------
/|\
|
map random cache
bytes to target
dependant i-face
/|\
|
target dependant
such as [gG] packet
or ptrace buffer
at the end of a command, high gdb could elect to tell the cache to purge
its self and that would in turn lead to the cache telling the target to
store_register() + do_defered_stores(). Having high gdb call
target_do_defered_stores() directly would need to be an interim measure.
Andrew