aboutsummaryrefslogtreecommitdiff
path: root/include/vms
diff options
context:
space:
mode:
authorAndrew Burgess <aburgess@redhat.com>2022-03-31 10:10:54 +0100
committerAndrew Burgess <aburgess@redhat.com>2022-04-07 16:01:18 +0100
commite7d69e72bfd16113a6bbbebfb8a92126245a4106 (patch)
tree6bc1c8d392f18dde3e1e499bc7bd455a3e5dc43b /include/vms
parent07c316ecaa2e47721b5e1281456e6b8b0d15c7ba (diff)
downloadgdb-e7d69e72bfd16113a6bbbebfb8a92126245a4106.zip
gdb-e7d69e72bfd16113a6bbbebfb8a92126245a4106.tar.gz
gdb-e7d69e72bfd16113a6bbbebfb8a92126245a4106.tar.bz2
gdb: always add the default register groups
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.
Diffstat (limited to 'include/vms')
0 files changed, 0 insertions, 0 deletions