diff options
author | Andrew Burgess <aburgess@redhat.com> | 2022-03-31 11:43:13 +0100 |
---|---|---|
committer | Andrew Burgess <aburgess@redhat.com> | 2022-04-07 16:01:18 +0100 |
commit | 1bca9b1e6be9cb45684f38dba0d4d323447a653a (patch) | |
tree | 1dd7781dc5cc99264f61bb158ef3329ef5edfbd0 /gdb/i386-tdep.c | |
parent | b89f77be528605fb1781bdd481c3ba1b9d6afab7 (diff) | |
download | fsf-binutils-gdb-1bca9b1e6be9cb45684f38dba0d4d323447a653a.zip fsf-binutils-gdb-1bca9b1e6be9cb45684f38dba0d4d323447a653a.tar.gz fsf-binutils-gdb-1bca9b1e6be9cb45684f38dba0d4d323447a653a.tar.bz2 |
gdb: remove reggroup_next and reggroup_prev
Add a new function gdbarch_reggroups that returns a reference to a
vector containing all the reggroups for an architecture.
Make use of this function throughout GDB instead of the existing
reggroup_next and reggroup_prev functions.
Finally, delete the reggroup_next and reggroup_prev functions.
Most of these changes are pretty straight forward, using range based
for loops instead of the old style look using reggroup_next. There
are two places where the changes are less straight forward.
In gdb/python/py-registers.c, the register group iterator needed to
change slightly. As the iterator is tightly coupled to the gdbarch, I
just fetch the register group vector from the gdbarch when needed, and
use an index counter to find the next item from the vector when
needed.
In gdb/tui/tui-regs.c the tui_reg_next and tui_reg_prev functions are
just wrappers around reggroup_next and reggroup_prev respectively.
I've just inlined the logic of the old functions into the tui
functions. As the tui function had its own special twist (wrap around
behaviour) I think this is OK.
There should be no user visible changes after this commit.
Diffstat (limited to 'gdb/i386-tdep.c')
0 files changed, 0 insertions, 0 deletions