Re: deferred stores as a solution to store register api?

[Andrew Cagney <ac131313 at cygnus dot com>]

"J.T. Conklin" wrote:

> Found in infrun.c and target.c to calls to target_clear_deferred_stores()
> and target_do_deferred_stores().
> 
> To take advantage of this, the target's .to_store_register() function
> might make a note that the register is to be saved instead of writing
> the register (or register set).  The target's ._do_deferred_stores()
> function could then make a reasonable decision how to write the reg
> values to the targets given the capabilities of the protocol.
> 
> Presumably this mechanism already works for sparc, at least sparc/sunos
> systems, so generalizing so it can be used by other targets should be
> doable.
> 
> Andrew>         (gdb) set $reg = value
> Andrew>
> Andrew> would such a write be defered as above or go out immediatly?
> 
> A believe that the actual write would be deferred.

Is this a good thing or a dangerous thing? (I'm playing devils
advocate.)

At present, when GDB is communicating with a remote target, it operates
``write through''.  Any memory/register update goes straight out while
reads can come from a cache (well for registers at least).  That way, if
the plug is pulled or (more likely :-) GDB dumps core, the target state
is up-to-date with respect to changes and the programmer can just resume
their debug session.

I agree with your comment that the target api needs to be extended so
that high-gdb can tell low-gdb (target) that it is performing a batched
update and, as you suggest, something like _defered_store() will make
that more efficient.  I just also think we may need to add some extra
code so that the existing behavour (each command is atomic ???) is also
retained.

	enjoy,
		Andrew