Re: Register group proposal

[Nick Duffek <nsd@redhat.com>]

On 21-Feb-2001, Andrew Cagney wrote:

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

Perhaps so.  It's not a struct at the moment, though, and even if it were,
declaring it as such implies that clients of the interface have access to
fields of the struct, which either (a) is untrue or (b) leaks internal
information across the interface.

I'd rather typedef it to something that'll cause compile-time errors if
it's used as anything other than an opaque handle.  That change probably
would require more discussion, so for now I'd prefer to use an int.

Going one step further, REGISTER_GROUPS should be defined as a pair of
FIRST/NEXT iterator macros plus a NAME macro:

  /* Return the first register group to display.  */
  int REGGROUP_FIRST (void)

  /* Return the register group to display after GRP.  -1 means there
     aren't any more groups to display.  */
  int REGGROUP_NEXT (int grp)

  /* Return the name of register group GRP.  */
  char *REGGROUP_NAME (int grp)

>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.

Yes, that's helpful for supporting Stephane's idea of using register
groups for purposes other than display, e.g. fetching and storing.

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

No, it never would be released, because it would be part of a gdbarch.
But this question is bypassed by the REGGROUP_FIRST change.

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

>Perhaphs

>	...._DEFAULT_REGROUP()

Agreed.

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

I proposed such a case in my original message:

  - 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.

Do you disagree with that case?  Even if you do, though, I don't think we
should impose restrictions on how architectures define register groups.

Nick