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?
- To: jtc at redback dot com
- Subject: Re: deferred stores as a solution to store register api?
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Fri, 12 May 2000 11:11:22 +1000
- CC: gdb at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <5m66skbwdg.fsf@jtc.redback.com>
"J.T. Conklin" wrote:
>
> As has been mentioned on this list before, the (to_store_register) API
> is deficient as it allows exactly one or all registers to be stored at
> a time. This leads to inefficiencies that add noticeable latency when
> using a remote debug protocol or rom monitor.
>
> One example is when a small set of registers (commonly pc, sp, and fp)
> are updated sequentially. If the target vector does not support a
> store single register command, the entire register set is written for
> each update. Another example is when a large number of registers are
> updated (for example restoring register values after an inferior
> function call). In this case, it would be more efficient to store all
> registers at once.
>
> I thinking this can be addressed with minimal impact by formalizing
> the CLEAR_DEFERRED_STORES and DO_DEFERRED_STORES macros currently used
> by the sunos/sparc port by making them part of the target vector. The
> vector code could then decide whether to store a single, a group, or a
> entire set of registers based on which registers are marked to be
> stored and the capabilities of the target.
How do you expect these extensions to the interface to be used?
Something like:
prepare_to_store ();
store_register ();
...
do_defered_stores ();
for a sequence of registers. What about for a single register? For
instance:
(gdb) set $reg = value
would such a write be defered as above or go out immediatly?
Andrew