This is the mail archive of the
mailing list for the GDB project.
Register group proposal
- To: insight at sources dot redhat dot com
- Subject: Register group proposal
- From: Nick Duffek <nsd at redhat dot com>
- Date: Wed, 21 Feb 2001 00:04:59 -0500
- CC: gdb at sources dot redhat dot com, fnasser at redhat dot com
On an architecture with a large register set, GDBtk's register window can
be difficult to read and slow to update. Users can customize the window
to hide individual registers, but that's a tedious procedure.
Therefore, users would benefit from being able to switch easily between
The CLI already provides two register subsets:
1. non-floating-point registers, displayed by "info registers";
2. all registers, displayed by "info all-registers".
This grouping is not as useful as it could be, for various reasons:
- Not all architectures have floating-point registers.
- Many architectures have non-floating-point registers that, like
floating-point registers, are only interesting to the user in special
circumstances and that therefore waste limited screen space in most
- Some pseudo-registers might not be appropriate in either "info
registers" or "info all-registers" output. For example, if an
architecture lacks a dedictated frame pointer register but its ABI
stores the frame pointer in general register r31, then "fp" and "r31"
might be aliases for the same register. It would not be useful to
display both fp and r31 in "info all-registers" output.
Whoever ports GDB to a particular architecture is likely to have a good
idea of what register groupings would be useful.
I propose the following gdbarch.sh macros with which architectures can
define register groupings:
/* Return a null-terminated list of register group names. */
char **REGISTER_GROUPS (void)
/* Return the REGISTER_GROUPS index of the group that "info registers"
should display. */
int REGISTERS_SOME (void)
/* Return the REGISTER_GROUPS index of the group that "info
all-registers" should display. */
int REGISTERS_ALL (void)
The register cache would define these gdbarch.sh macros:
/* Return the number of the first register to display in GROUP, which is
an index in REGISTER_GROUPS. */
int REGISTER_INFO_FIRST (int group)
/* Return the number of the register to display after register REGNUM
in GROUP, which is an index in REGISTER_GROUPS. If no registers
should be displayed after register REGNUM, return -1. */
int REGISTER_INFO_NEXT (int group, int regnum)
GDBtk could use REGISTER_GROUPS to generate a menu of register windows.
Users could still customize window contents, but the predefined sets
might make customization unnecessary for most users.
The CLI "info registers" command already accepts a register name as an
optional paramter. It could be extended to try that parameter as a group
name first and a register name second, so e.g. "info registers float"
would display all floating-point registers.
What do you think?