Andrew Burgess e7d69e72bf 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.
2022-04-07 16:01:18 +01:00
2022-01-22 12:08:55 +00:00
2020-09-25 10:24:44 -04:00
2022-01-22 12:08:55 +00:00
2022-01-22 12:08:55 +00:00
2021-11-15 12:20:12 +10:30
2022-04-06 11:10:40 -04:00
2022-01-28 08:25:42 -05:00
2022-03-11 08:58:31 +00:00
2022-03-11 08:58:31 +00:00
2022-03-11 08:58:31 +00:00
2022-03-11 08:58:31 +00:00
2021-11-13 09:04:03 -08:00
2022-03-11 08:58:31 +00:00

		   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.
S
Description
Yggdrasil port of GNU Binutils
Readme 418 MiB