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

Simon Marchi via Gdb-patches
2022-04-06T13:23:18Z

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