mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-09 04:21:49 +08:00
e7d69e72bf
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. |
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gdbserver | ||
| gdbsupport | ||
| gnulib | ||
| gold | ||
| gprof | ||
| gprofng | ||
| include | ||
| intl | ||
| ld | ||
| libbacktrace | ||
| libctf | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| ar-lib | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| lt~obsolete.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| multilib.am | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release.sh | ||
| symlink-tree | ||
| test-driver | ||
| ylwrap | ||
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.