public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: insight@sources.redhat.com, gdb@sources.redhat.com, fnasser@redhat.com
Subject: Re: Register group proposal
Date: Wed, 21 Feb 2001 12:18:00 -0000	[thread overview]
Message-ID: <3A942228.C9E05495@cygnus.com> (raw)
In-Reply-To: <200102210504.f1L54xJ01509@rtl.cygnus.com>

Nick Duffek wrote:

Several thoughts on the interface.  Again mostly generic.

--

Rather than a simple integer, should reggroup be made an object vis
``struct reggroup *''?

I think one of the maintenance problems with GDB's current internals is
that it uses integers for many and varied things.  It is just too easy
to pass an integer intended for one purpose to a function where the
meaning is different.  It is also too easy to extract implied
information from it.

As an example, GDB kicks around a REGNUM when, it really means two
separate things - a register that is part of a frame; and an entry in
the raw register cache.  If REGNUM, was strongly typed the separation of
the two uses would be forced.  While that won't happen to REGNUM for a
very long time, I would like newer types to be made strongly typed so
that the same mistakes are less likely to happen again.

This may affect things like ``REGISTER_GROUPS()''.

Even if it isn't made an object could I suggest the convention of a
...._REGGROUP() be adopted to all methods that return a register group.

--

The interface defines an iterator:

>   /* 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)

I guess this is called as something like (I'll take the liberty of using
slightly different names):

	for (regnum = REGGROUP_FIRST_REGNUM (reggroup);
	     regnum >= 0;
	     retnum = REGGROUP_NEXT_REGNUM (reggroup, regnum))
	  {
	     apply regnum;
	  }

As an iterator it is the natural choice.  Perhaphs it should be adopted
as the convention to use when both a GDB object needs an iterator and
the members of that list are constant (reggrop won't change but the
breakpoint list could change).





--

>   /* Return a null-terminated list of register group
> names.  */
>   char **REGISTER_GROUPS (void)

Would such a table be released using freeargv() like many of the BFD
interfaces?

>   /* Return the REGISTER_GROUPS index of the group that
> "info registers"
>      should display.  */
>   int REGISTERS_SOME (void)

Perhaphs

	...._DEFAULT_REGROUP()

>   /* Return the REGISTER_GROUPS index of the group that
> "info
>      all-registers" should display.  */
>   int REGISTERS_ALL (void)

Hmm, is there a case when ``info all-registers'' doesn't display all the
registers?

	Andrew

  parent reply	other threads:[~2001-02-21 12:18 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-20 20:56 Nick Duffek
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 [this message]
2001-02-22  0:59   ` Eli Zaretskii
2001-02-22  4:29     ` Nick Duffek
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  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-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=3A942228.C9E05495@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=fnasser@redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=insight@sources.redhat.com \
    --cc=nsd@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).