Register group proposal

[Nick Duffek <nsd 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
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