Proposal for handling large numbers of registers

J.T. Conklin
Mon Aug 9 16:31:00 GMT 1999

>>>>> "Stan" == Stan Shebs <> writes:
Stan> So I'm considering importing the idea of "register classes" from
Stan> GCC.  

This seems to fit well into my strawman proposal for a remote protocol
extension to store and fetch groups of registers.

Stan> GCC uses the class idea to guide allocation and instruction
Stan> selection, but we don't even need that much; just define the
Stan> names of the classes and which registers belong to each.

GCC's register classes are defined on a per-processor basis.  Are you
thinking of using that model, or one where registers are fit into a
pre-defined set of classes?  I think compelling arguments could be
made on each side.

Stan> In a minimal model, each register belongs to exactly one class.
Stan> A more sophisticated model would allow registers to belong to
Stan> multiple classes, 

Which model are you leaning towards?  I suspect that this decision
will have significant implementation implications.

Stan> although I think you'd want to have a primary class for each
Stan> register, so that GUIs can construct a hierarchical list of
Stan> registers by class, where each register appears exactly once.

IMO, whether a single class or multiple class representation is used
should not have an impact on presentation.  I strongly believe that
users should be able to create arbitrary "classes" and decide which
registers are to be displayed in each.  Using the internal register
classes is a poor substitute for this.  In fact, a logical extension
is the ability for users to define their own "virtual" registers for
memory mapped I/O devices.

Stan> To go along with this, it would be useful to able to identify a
Stan> class of registers that are always fetched from targets.

Always fetched for what purpose?

A lazy fetch scheme should be workable.  When the user invokes 'info
registers' or has a GUI register window open with the appropriate
class 'un-clicked', the needed registers should be fetched.

Stan> Typically these would be the ones saved and restored by traps,
Stan> and so would not include special registers, but that would be up
Stan> to the person doing the GDB and target-side stub port.  I could
Stan> also see adding an option to "info registers" to only display
Stan> these, and redefining it and "info all-registers" to base their
Stan> behavior upon agreed-upon classes, rather than always being
Stan> wired to float/non-float classes as they are now.

Oh, what you are asking is what registers should be displayed with
'info registers'.  Perhaps a variable would contain a list of what
registers and register classes are displayed.  Maybe something like

        set info-register-list int sys

Would tell 'info register' to display registers from the 'int' and
'sys' classes?


J.T. Conklin 
RedBack Networks

More information about the Gdb mailing list