Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Nick Duffek <nsd@redhat.com>
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	[thread overview]
Message-ID: <200102210504.f1L54xJ01509@rtl.cygnus.com> (raw)

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


             reply	other threads:[~2001-02-20 20:56 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-20 20:56 Nick Duffek [this message]
2001-02-21  6:44 ` Fernando Nasser
2001-02-21  7:10   ` Nick Duffek
2001-02-21  7:36     ` Fernando Nasser
2001-02-21  7:58     ` Keith Seitz
2001-02-21  8:50 ` Andrew Cagney
2001-02-21 11:43   ` Andrew Cagney
2001-02-25 15:36   ` Nick Duffek
2001-02-21 11:43 ` Andrew Cagney
2001-02-21 12:28   ` Andrew Cagney
2001-02-21 12:18 ` Andrew Cagney
2001-02-22  0:59   ` Eli Zaretskii
     [not found]     ` <200102221237.f1MCbtX02766@rtl.cygnus.com>
2001-02-22  8:46       ` Andrew Cagney
2001-02-22  8:56         ` Keith Seitz
2001-02-22  9:20           ` Andrew Cagney
2001-02-22  5:17   ` Nick Duffek
2001-02-22  6:36     ` Fernando Nasser
2001-02-22  8:23       ` Andrew Cagney
2001-02-22  7:58     ` Andrew Cagney
2001-02-22  8:37       ` Nick Duffek
2001-02-22  9:12         ` Andrew Cagney
2001-02-22 10:15           ` Nick Duffek
2001-02-22 10:25             ` Andrew Cagney
2001-02-22 11:40               ` Eli Zaretskii
2001-02-22 11:02           ` Kevin Buettner
2001-02-22 12:08             ` Andrew Cagney
2001-02-22  8:16     ` Andrew Cagney
2001-02-21  3:00 Stephane Carrez
2001-02-21  7:00 ` Nick Duffek
2001-02-21  9:34 ` Andrew Cagney
2001-02-22  9:19 Michael Elizabeth Chastain
2001-02-23  2:52 Bernard Dautrevaux
2001-02-24 15:43 ` Nick Duffek
2001-02-26 18:21   ` Andrew Cagney
2001-02-27 10:30     ` Jim Kleck
2001-02-27 11:24       ` Per Bothner
2001-02-27 13:44         ` Jim Kleck
2001-02-27 15:17           ` Andrew Cagney
2001-02-26  5:29 Bernard Dautrevaux
2001-02-26  9:28 ` Christopher Faylor
2001-02-26 10:56   ` Andrew Cagney
2001-02-26 11:28     ` Christopher Faylor
2001-02-26 17:02       ` Andrew Cagney
2001-02-27  8:53         ` Christopher Faylor
2001-02-27  9:57           ` Andrew Cagney
2001-02-28  1:59 Bernard Dautrevaux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200102210504.f1L54xJ01509@rtl.cygnus.com \
    --to=nsd@redhat.com \
    --cc=fnasser@redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=insight@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox