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

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> How do you expect these extensions to the interface to be used? 
Andrew> Something like:
Andrew>
Andrew> 	prepare_to_store ();
Andrew> 	store_register ();
Andrew> 	...
Andrew> 	do_defered_stores ();
Andrew>
Andrew> for a sequence of registers.  What about for a single register?  For
Andrew> instance:

No, I was thinking of replacing the instances of:

        #ifdef CLEAR_DEFERRED_STORES
                CLEAR_DEFERRED_STORES
        #endif

and:
        #ifdef DO_DEFERRED_STORES
                DO_DEFERRED_STORES;
        #endif

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.

        --jtc

-- 
J.T. Conklin
RedBack Networks