From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Duffek To: insight@sources.redhat.com Cc: gdb@sources.redhat.com, fnasser@redhat.com Subject: Register group proposal Date: Tue, 20 Feb 2001 20:56:00 -0000 Message-id: <200102210504.f1L54xJ01509@rtl.cygnus.com> X-SW-Source: 2001-q1/msg00183.html 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 register subsets. 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 circumstances. - 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? Nick