Re: [PATCHv2 09/16] gdb: always add the default register groups

[Simon Marchi <simon.marchi@polymtl.ca>]

On 2022-04-06 08:04, Andrew Burgess via Gdb-patches wrote:
> There's a set of 7 default register groups.  If we don't add any
> gdbarch specific register groups during gdbarch initialisation, then
> when we iterate over the register groups using reggroup_next and
> reggroup_prev we will make use of these 7 default groups.  See the use
> of default_groups in gdb/reggroups.c for details on this.
> 
> However, if the gdbarch adds its own groups during gdbarch
> initialisation, then these groups will be used in preference to the
> default groups.
> 
> A problem arises though if the particular architecture makes use of
> the target description mechanism.  If the default target
> description(s) (i.e. those internal to GDB that are used when the user
> doesn't provide their own) don't mention any additional register
> groups then the default register groups will be used.
> 
> But if the target description does mention additional groups then the
> default groups are not used, and instead, the groups from the target
> description are used.
> 
> The problem with this is that what usually happens is that the target
> description will mention additional groups, e.g. groups for special
> registers.  Most architectures that use target descriptions work
> around this by adding all (or most) of the default register groups in
> all cases.  See i386_add_reggroups, aarch64_add_reggroups,
> riscv_add_reggroups, xtensa_add_reggroups, and others.
> 
> In this patch, my suggestion is that we should just add the default
> register groups for every architecture, always.  This change is in
> gdb/reggroups.c.
> 
> All the remaining changes are me updating the various architectures to
> not add the default groups themselves.
> 
> So, where will this change be visible to the user?  I think the
> following commands will possibly change:
> 
> * info registers / info all-registers:
> 
>   The user can provide a register group to these commands.  For example,
>   on csky, we previously never added the 'vector' group.  Now, as a
>   default group, this will be available, but (presumably) will not
>   contain any registers.  I don't think this is necessarily a bad
>   thing, there's something to be said for having some consistent
>   defaults available.  There are other architectures that didn't add
>   all 7 of the defaults, which will now have gained additional groups.
> 
> * maint print reggroups
> 
>   This prints the set of all available groups.  As a maintenance
>   command I'm less concerned with the output changing here.
>   Obviously, for the architectures that didn't previously add all the
>   defaults, this list just got bigger.
> 
> * maint print register-groups
> 
>   This prints all the registers, and the groups they are in.  If the
>   defaults were not previously being added then a register (obviously)
>   can't appear in one of the default groups.  Now the groups are
>   available then registers might be in more groups than previously.
>   However, this is again a maintenance command, so I'm less concerned
>   about this changing.

That sounds reasonable to me.

> @@ -119,13 +110,44 @@ reggroup_add (struct gdbarch *gdbarch, struct reggroup *group)
>    struct reggroups *groups
>      = (struct reggroups *) gdbarch_data (gdbarch, reggroups_data);
>  
> +  /* The same reggroup should not be added multiple times.  */
> +  gdb_assert (groups != nullptr);
> +  for (struct reggroup_el *el = groups->first;
> +       el != nullptr;
> +       el = el->next)
> +    gdb_assert (group != el->group);

The "for" can be on a single line.

Simon