This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

deferred stores as a solution to store register api?


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]