This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
deferred stores as a solution to store register api?
- To: gdb at sourceware dot cygnus dot com
- Subject: deferred stores as a solution to store register api?
- From: jtc at redback dot com (J.T. Conklin)
- Date: 11 May 2000 14:38:35 -0700
- Reply-To: jtc at redback dot com
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.
The target macros could be defined like:
#define target_clear_deferred_stores() \
do { \
if (current_target.to_clear_deferred_stores) \
(current_target.to_clear_deferred_stores)(); \
} while (0)
#define target_do_deferred_stores() \
do { \
if (current_target.to_do_deferred_stores) \
(current_target.to_do_deferred_stores(); \
} while (0)
So that null functions wouldn't have to be added to all the target
vectors (why don't we do this for target_prepare_to_store() while
we're at it?, several target vectors have their own do-nothing
function for this).
Thoughts?
--jtc
--
J.T. Conklin
RedBack Networks