This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Proposal for handling large numbers of registers
- To: Stan Shebs <shebs@cygnus.com>
- Subject: Re: Proposal for handling large numbers of registers
- From: jtc@redback.com (J.T. Conklin)
- Date: 09 Aug 1999 16:29:51 -0700
- Cc: gdb@sourceware.cygnus.com
- References: <199908062333.QAA16667@andros.cygnus.com>
- Reply-To: jtc@redback.com
>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> 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?
--jtc
--
J.T. Conklin
RedBack Networks