binutils_os216

Fork

libctf: add some missing #includes.

Causes warnings on (at least) recent FreeBSD.

libctf/
* ctf-create.c: Include <unistd.h>.
* ctf-open-bfd.c: Likewise.

libctf, elfcpp, gold: do not assume that <byteswap.h> contains bswap_*

At least one C library (uclibc-ng) defines some of these only when
the compiler is GCC. We might as well test for all three cases and
handle any of them being missing.

Very similar code exists in libctf and split between elfcpp and gold:
fix both.

(Also sync up elfcpp with a change made to libctf swap.h a few months
ago: since there is no out-of-line definition of the bswap replacements,
they should be declared static inline, not just inline, to prevent the
linker generating out-of-line references to them.)

PR libctf/25120
libctf/
* configure.ac: Check for bswap_16, bswap_32, and bswap_64 decls.
* swap.h (bswap_16): Do not assume that presence of <byteswap.h>
means this is declared.
(bswap_32): Likewise.
(bswap_64): Likewise.
(bswap_identity_64): Remove, unused.
* configure: Regenerated.
* config.h.in: Likewise.
gold/
* configure.ac: Check for bswap_16, bswap_32, and bswap_64 decls.
* configure: Regenerated.
* config.h.in: Likewise.
elfcpp/
* elfcpp_swap.h (bswap_16): Do not assume that presence of
<byteswap.h> means this is declared. Make static inline, matching
recent change to libctf, since there is no non-inline definition
of these functions.
(bswap_32): Likewise.
(bswap_64): Likewise.

libctf: work with compilers not supporting GNU C attributes

The obvious fallback __attribute__ stanza was missing.

Thanks to Harald van Dijk.

PR 25120
libctf/
* ctf-impl.h (_libctf_printflike_): Add non-GNU-C fallback.
(_libctf_unlikely_): Likewise.
(_libctf_unused): Likewise.
(_libctf_malloc_): Likewise.

libctf: avoid nonportable __thread in CTF archive handling

This keeps archive searching threadsafe using the new bsearch_r that was
just added to libiberty.

PR25120
libctf/
* ctf-archive.c (search_nametbl): No longer global: declare...
(ctf_arc_open_by_name_internal): ... here. Use bsearch_r.
(search_modent_by_name): Take and use ARG for the nametbl.

libctf, binutils: support CTF archives like objdump

objdump and readelf have one major CTF-related behavioural difference:
objdump can read .ctf sections that contain CTF archives and extract and
dump their members, while readelf cannot. Since the linker often emits
CTF archives, this means that readelf intermittently and (from the
user's perspective) randomly fails to read CTF in files that ld emits,
with a confusing error message wrongly claiming that the CTF content is
corrupt. This is purely because the archive-opening code in libctf was
needlessly tangled up with the BFD code, so readelf couldn't use it.

Here, we disentangle it, moving ctf_new_archive_internal from
ctf-open-bfd.c into ctf-archive.c and merging it with the helper
function in ctf-archive.c it was already using. We add a new public API
function ctf_arc_bufopen, that looks very like ctf_bufopen but returns
an archive given suitable section data rather than a ctf_file_t: the
archive is a ctf_archive_t, so it can be called on raw CTF dictionaries
(with no archive present) and will return a single-member synthetic
"archive".

There is a tiny lifetime tweak here: before now, the archive code could
assume that the symbol section in the ctf_archive_internal wrapper
structure was always owned by BFD if it was present and should always be
freed: now, the caller can pass one in via ctf_arc_bufopen, wihch has
the usual lifetime rules for such sections (caller frees): so we add an
extra field to track whether this is an internal call from ctf-open-bfd,
in which case we still free the symbol section.

include/
* ctf-api.h (ctf_arc_bufopen): New.
libctf/
* ctf-impl.h (ctf_new_archive_internal): Declare.
(ctf_arc_bufopen): Remove.
(ctf_archive_internal) <ctfi_free_symsect>: New.
* ctf-archive.c (ctf_arc_close): Use it.
(ctf_arc_bufopen): Fuse into...
(ctf_new_archive_internal): ... this, moved across from...
* ctf-open-bfd.c: ... here.
(ctf_bfdopen_ctfsect): Use ctf_arc_bufopen.
* libctf.ver: Add it.
binutils/
* readelf.c (dump_section_as_ctf): Support .ctf archives using
ctf_arc_bufopen. Automatically load the .ctf member of such
archives as the parent of all other members, unless specifically
overridden via --ctf-parent. Split out dumping code into...
(dump_ctf_archive_member): ... here, as in objdump, and call
it once per archive member.
(dump_ctf_indent_lines): Code style fix.

libctf: create: forwards are always in the namespace of their referent

The C namespace a forward is located in is always the same as the
namespace of the corresponding complete type: 'struct foo' is in the
struct namespace and does not collide with, say, 'union foo'.

libctf allowed for this in many places, but inconsistently: in
particular, forward *addition* never allowed for this, and was interning
forwards in the default namespace, which is always wrong, since you can
only forward structs, unions and enums, all of which are in their own
namespaces in C.

Forward removal needs corresponding adjustment to remove the names form
the right namespace, as does ctf_rollback.

libctf/
* ctf-create.c (ctf_add_forward): Intern in the right namespace.
(ctf_dtd_delete): Remove correspondingly.
(ctf_rollback): Likewise.

libctf: create: ctf_add_type should hand back already-added non-SoUs

When we add a type from a dictionary and then try to add it again, we
should hand it back unchanged unless it is a structure, union or enum
with a different number of members. That's what the comment says we do.

Instead, we hand it back unchanged *only* if it is a structure, union or
enum with the same number of members: non-structs, unions and enums are
unconditionally added. This causes extreme type bloating and (in
conjunction with the bug fixed by the next commit) can easily lead to
the same type being mistakenly added to a dictionary more than once
(which, for forwards, was not banned and led to dictionary corruption).

libctf/
* ctf-create.c (ctf_add_type_internal): Hand back existing types
unchanged.

libctf: create: don't add forwards if the type added already exists

This is what ctf_add_forward is documented to do, but it's not what it
actually does: the code is quite happy to add forwards that duplicate
existing structs, etc.

This is obviously wrong and breaks both the nondeduplicating linker
and the upcoming deduplicator, as well as allowing ordinary callers of
ctf_add_type to corrupt the dictionary by just adding the same root-
visible forward more than once.

libctf/
* ctf-create.c (ctf_add_forward): Don't add forwards to
types that already exist.

libctf: create: non-root-visible types should not appear in name tables

We were accidentally interning newly-added and newly-opened
non-root-visible types into name tables, and removing names from name
tables when such types were removed. This is very wrong: the whole
point of non-root-visible types is they do not go in name tables and
cannot be looked up by name. This bug made non-root-visible types
basically identical to root-visible types, right back to the earliest
days of libctf in the Solaris era.

libctf/
* ctf-open.c (init_types): Only intern root-visible types.
* ctf-create.c (ctf_dtd_insert): Likewise.
(ctf_dtd_delete): Only remove root-visible types.
(ctf_rollback): Likewise.
(ctf_add_generic): Adjust.
(ctf_add_struct_sized): Adjust comment.
(ctf_add_union_sized): Likewise.
(ctf_add_enum): Likewise.
* ctf-impl.h (ctf_dtd_insert): Adjust prototype.

binutils, ld: work with --disable-libctf

This unfortunately means conditionalizing out all the libctf code, but
the result is not too unbearably ugly, if a bit repetitive. I have
stubbed out code in the !ENABLE_LIBCTF path to avoid extra redundant
ifdefs where it seems that might be helpful. (The stubs are not too
disruptive, but I've tried to keep them on one line where possible to
avoid filling up the screen with stubs that nobody would care about.
If this is too much of a coding style violation I can change it.)

Changes since v2: use GCC_ENABLE rather than repeating all the
AC_ARG_ENABLE stuff over and over again.

ld/
* configure.ac [--enable-libctf]: New, default yes.
Set ENABLE_LIBCTF accordingly.
* Makefile.am [!ENABLE_LIBCTF]: Empty LIBCTF.
* configure: Regenerate.
* config.in: Regenerate.
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.
* ldlang.c (ctf_output): Conditionalize on ENABLE_LIBCTF.
(ldlang_open_ctf): Likewise.
(lang_merge_ctf): Likewise.
(ldlang_ctf_apply_strsym): Likewise.
(lang_write_ctf): Likewise.
(ldlang_write_ctf_late): Likewise.
(ldlang_open_ctf) [!ENABLE_LIBCTF]: Warn about the presence of CTF
sections.
(lang_merge_ctf) [!ENABLE_LIBCTF]: New stub.
(ldlang_ctf_apply_strsym) [!ENABLE_LIBCTF]: Likewise.
(lang_write_ctf) [!ENABLE_LIBCTF]: Likewise.
(ldlang_write_ctf_late) [!ENABLE_LIBCTF]: Likewise.
* ldelfgen.c (ldelf_emit_ctf_early): Conditionalize on
ENABLE_LIBCTF.
(struct ctf_strsym_iter_cb_arg): Likewise.
(ldelf_ctf_strtab_iter_cb): Likewise.
(ldelf_ctf_symbols_iter_cb): Likewise.
(ldelf_examine_strtab_for_ctf): Likewise.
(ldelf_emit_ctf_early) [!ENABLE_LIBCTF]: New stub.
(ldelf_examine_strtab_for_ctf) [!ENABLE_LIBCTF]: New stub.

binutils/
* configure.ac [--enable-libctf]: New, default yes.
Set ENABLE_LIBCTF accordingly.
* Makefile.am [!ENABLE_LIBCTF]: Empty LIBCTF and LIBCTF_NOBFD.
* configure: Regenerate.
* config.in: Regenerate.
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.
* objdump.c (usage): Conditionalize portions on ENABLE_LIBCTF.
(option_values): Likewise.
(long_options): Likewise.
(main): Likewise.
(dump_ctf_indent_lines): Conditionalize out when !ENABLE_LIBCTF.
(make_ctfsect): Likewise.
(dump_ctf_archive_member): Likewise.
(dump_ctf) [ENABLE_LIBCTF]: Likewise.
(dump_ctf) [!ENABLE_LIBCTF]: New empty stub.
* readelf.c (options): Conditionalize portions on ENABLE_LIBCTF.
(usage): Likewise.
(process_section_contents): Likewise.
(shdr_to_ctf_sect): Conditionalize out when !ENABLE_LIBCTF.
(dump_ctf_indent_lines): Likewise.
(dump_section_as_ctf) [ENABLE_LIBCTF]: Likewise.

Fix --enable-libctf and --disable-static

This fixes test runs and compilation when --disable-libctf,
--disable-static, or --enable-shared are passed.

Changes since v2: Use GCC_ENABLE and fix indentation. Fix prototype
using 'void'. Use 'unsupported' and gdb_caching_proc.

Changes since v3: Adapt to upstream changes providing skip_ctf_tests.

Changes since v4: Adapt to upstream changes in the seven months (!)
since I last looked at this.

gdb/ChangeLog
* configure.ac: Add --enable-libctf: handle --disable-static
properly.
* acinclude.m4: sinclude ../config/enable.m4.
* Makefile.in (aclocal_m4_deps): Adjust accordingly.
(LIBCTF): Substitute in.
(CTF_DEPS): New, likewise.
(CLIBS): libctf needs symbols from libbfd: move earlier.
(CDEPS): Use CTF_DEPS, not LIBCTF, now LIBCTF can include rpath
flags.
* ctfread.c: Surround in ENABLE_LIBCTF.
(elfctf_build_psymtabs) [!ENABLE_LIBCTF]: New stub.
* configure: Regenerate.
* config.in: Likewise.

gdb/testsuite/ChangeLog
* configure.ac: Add --enable-libctf.
* aclocal.m4: sinclude ../config/enable.m4.
* Makefile.in (site.exp): Add enable_libctf to site.exp.
* lib/gdb.exp (skip_ctf_tests): Use it.
* gdb.base/ctf-constvars.exp: Error message tweak.
* gdb.base/ctf-ptype.exp: Likewise.
* configure: Regenerate.

x86: make I disassembler macro available for new use

The {Q|Q} construct on lgdt/lidt and the slightly different {Q|IQ}
struck me as odd when encountering. Realizing they both have the same
effect, let's free up the I macro by using the former form of construct
where needed (there aren't that many uses overall).

With there now being several multi-character macros also re-do "alt"
handling slightly: Terminate it when finding the closing brace, rather
than after the next single character. Also set the flag only when
actually in Intel syntax mode.

ld/x86: actually invoke k1om tests

Unlike claimed by the ChangeLog entries added by 7a9068fe1646 ("Add
initial Intel K1OM support") these tests did never get enabled.

x86: fix processing of -M disassembler option

Multiple -M options can be specified in any order. Therefore stright
assignment to fields affected needs to be avoided, such that earlier
options' effects won't be discarded. This was in particular a problem
for -Msuffix followed by certain of the other sub-options.

While updating documentation, take the liberty and also drop the
redundant mentioning of being able to comma-separate multiple options.

Fix -Wstring-compare testcase build failure

Clang fails to compile the file gdb/testsuite/gdb.cp/try_catch.cc
with the following error:
warning: result of comparison against a string literal is
unspecified (use strncmp instead) [-Wstring-compare]

This commit fixes the error, replacing the pointer comparison with
a call to strcmp. This commit also adds a final check: the test
program is run to the final return statement, and the value of
"test" is checked to ensure it is still "true" at that point.

gdb/testsuite/ChangeLog:

* gdb.cp/try_catch.cc: Include string.h.
(main): Replace comparison against string literal with
strcmp, avoiding build failure with -Wstring-compare.
Add "marker test-complete".
* gdb.cp/try_catch.exp: Run the test to the above marker,
then verify that the value of "test" is still true.

Improve documentation of which shell is used by GDB's shell commands

gdb/doc/ChangeLog:

2020-06-26 Eli Zaretskii <eliz@gnu.org>

* gdb.texinfo (Shell Commands): More accurate description of use
of $SHELL. Reported by Sandra Loosemore <sandra@codesourcery.com>.

m68k: tag floating-point ABI used

This patch adds GNU attribute support to m68k and utilises it to tag the
floating-point calling convention used (hard-float or soft-float). It enables
the linker to ensure linked objects use a consistent floating-point ABI and
allows tools like GDB to infer the ABI used from the ELF file. It is based on
similar work done for PowerPC.

bfd/
* elf32-m68k.c (m68k_elf_merge_obj_attributes): New function.
(elf32_m68k_merge_private_bfd_data): Merge GNU attributes.
binutils/
* readelf.c (display_m68k_gnu_attribute): New function.
(process_arch_specific): Call display_m68k_gnu_attribute for EM_68K.
gas/
* config/tc-m68k.c (m68k_elf_gnu_attribute): New function.
(md_pseudo_table): Handle "gnu_attribute".
* doc/as.texi: Document GNU attribute for M68K.
include/
* elf/m68k.h: Add enum for GNU object attribute with floating point
tag name and values.
ld/
* testsuite/ld-m68k/attr-gnu-4-0.s: New file.
* testsuite/ld-m68k/attr-gnu-4-1.s: Likewise.
* testsuite/ld-m68k/attr-gnu-4-2.s: Likewise.
* testsuite/ld-m68k/attr-gnu-4-00.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-01.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-02.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-10.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-11.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-12.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-20.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-21.d: Likewise.
* testsuite/ld-m68k/attr-gnu-4-22.d: Likewise.
* testsuite/ld-m68k/m68k.exp: Run the new tests.

RISCV changes broke 32-bit --enable-targets=all

By the look of it, git commit 39ff0b812324 broke 32-bit host
--enable-targets=all binutils builds.

/usr/local/bin/ld: ../opcodes/.libs/libopcodes.a(riscv-dis.o): in function `parse_riscv_dis_option':
/home/alan/src/binutils-gdb/opcodes/riscv-dis.c:102: undefined reference to `riscv_get_priv_spec_class'
collect2: error: ld returned 1 exit status
Makefile:925: recipe for target 'objdump' failed

The problem is that elfxx-riscv.c is not built for a 32-bit host
without --enable-64-bit-bfd or unless RISCV is given specifically as a
target. No such trimming of 64-bit only targets is done in opcodes.

One solution is to move these support functions to cpu-riscv.c, which
runs into "error: implicit declaration of function ‘xmalloc’". Now,
xmalloc is not supposed to be used in libbfd or libopcodes - it's rude
to crash out of an application that calls libbfd or libopcodes
functions without giving it a chance to deal with out-of-memory
itself. So I removed the xmalloc and instead used a fixed size
buffer. If you are worried about adding 36 bytes for the buffer to
the riscv_get_priv_spec_class_from_numbers stack frame size, then you
have no idea of the likely xmalloc + malloc stack frame size! Trying
to reduce memory usage is commendable, but in this instance
riscv_estimate_digit and malloc for a temp buffer uses a lot more
memory than a fixed max-size buffer.

* elfxx-riscv.c (struct priv_spec_t, priv_specs),
(riscv_get_priv_spec_class, riscv_get_priv_spec_class_from_numbers),
(riscv_get_priv_spec_name): Move to..
* cpu-riscv.c: ..here.
(riscv_get_priv_spec_class_from_numbers): Don't xmalloc temp buffer.
Use %u to print unsigned numbers.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb: use make_unique_xstrdup in set_inferior_io_terminal

gdb/ChangeLog:

* infcmd.c (set_inferior_io_terminal): Use make_unique_xstrdup.

Change-Id: I38b6e753f58947531fe4a293d574bc27ec128f47

gdb: make inferior::terminal a unique ptr

This changes the inferior::terminal field to be a unique pointer, so its
deallocation is automatically managed.

gdb/ChangeLog:

* inferior.h (struct inferior) <terminal>: Change type to
gdb::unique_xmalloc_ptr<char>.
* inferior.c (inferior::~inferior): Don't free inf->terminal.
* infcmd.c (set_inferior_io_terminal): Don't free terminal
field, adjust to unique pointer.
(get_inferior_io_terminal): Adjust to unique pointer.

Change-Id: Iedb6459b4f9eeae812b0cb9d514b5707d5107cdb

cpu: fix offset16 type, update c-calls in bpf.cpu

Correct the type of the offset16 field to HI, and simplify memory
accesses which use it. Also update c-calls in semantics for a
few instructions.

cpu/ChangeLog:

2020-06-25 David Faust <david.faust@oracle.com>

* bpf.cpu (f-offset16): Change type from INT to HI.
(dxli): Simplify memory access.
(dxsi): Likewise.
(define-endian-insn): Update c-call in semantics.
(dlabs) Likewise.
(dlind) Likewise.

gdb/riscv: Loop over all registers for 'info all-registers'

Currently the 'info all-registers' command only loops over those
registers that are known to GDB. Any registers that are unknown, that
is, are mentioned in the target description, but are not something GDB
otherwise knows, will not be displayed.

This feels wrong, so this commit fixes this mistake. The output of
'info all-registers' now matches 'info registers all'.

gdb/ChangeLog:

* riscv-tdep.c (riscv_print_registers_info): Loop over all
registers, not just the known core set of registers.

gdb/testsuite/ChangeLog:

* gdb.arch/riscv-tdesc-regs.exp: New test cases.

gdb/riscv: Record information about unknown tdesc registers

Making use of the previous commit, record information about unknown
registers in the target description, and use this to resolve two
issues.

1. Some targets (QEMU) are reporting three register fflags, frm, and
fcsr, twice, once in the FPU feature, and once in the CSR feature.
GDB does create two registers with identical names, but this
is (sort of) fine, we only ever use the first one, and as both
registers access the same target state things basically work OK.
The only real problem is that the register names show up twice in
'info registers all' output.

In this commit we spot the duplicates of these registers and then
return NULL when asked for the name of these registers. This
causes GDB to hide these registers from the user, fixing this
problem.

2. Some targets (QEMU) advertise CSRs that GDB then can't read. The
problem is these targets also say these CSRs are part of the
save/restore register groups.

This means that before an inferior call GDB tries to save all of
these CSRs, and a failure to read one causes the inferior call to
be abandoned.

We already work around this issue to some degree, known CSRs are
removed from the save/restore groups, despite what the target might
say. However, any unknown CSRs are (currently) not removed in this
way.

After this commit we keep a log of the register numbers for all
unknown CSRs, then when asked about the register groups, we
override the group information for unknown CSRs, removing them from
the save and restore groups.

gdb/ChangeLog:

* riscv-tdep.c (riscv_register_name): Return NULL for duplicate
fflags, frm, and fcsr registers.
(riscv_register_reggroup_p): Remove unknown CSRs from save and
restore groups.
(riscv_tdesc_unknown_reg): New function.
(riscv_gdbarch_init): Pass riscv_tdesc_unknown_reg to
tdesc_use_registers.
* riscv-tdep.h (struct gdbarch_tdep): Add
unknown_csrs_first_regnum, unknown_csrs_count,
duplicate_fflags_regnum, duplicate_frm_regnum, and
duplicate_fcsr_regnum fields.

gdb/testsuite/ChangeLog:

* gdb.arch/riscv-tdesc-regs.exp: Extend test case.

gdb: Extend target description processing of unknown registers

This commit adds a new step to the processing of a target description
done in tdesc_use_registers, this new step is about how unknown
registers are processed.

Currently an architecture looks through the target description and
calls tdesc_numbered_register for each register is was expecting (or
hoping) to find. This builds up a map from GDB's register numbers to
the tdesc_reg object. Later the architecture calls
tdesc_use_registers.

In tdesc_use_registers we build a hash with keys being all the
tdesc_reg object pointers, from this hash we remove all of the
tdesc_reg objects that were assigned register numbers using
tdesc_numbered_register.

Finally we walk through all of the tdesc_reg objects, and if it was
not already assigned a number we assign that register the next
available number.

The problem with this is that the architecture has no visibility of
which unknown registers exist, and which tdesc_feature the register
came from, in some cases this might be important.

For example, on RISC-V GDB overrides the use of
tdesc_register_reggroup_p, with riscv_register_reggroup_p to modify
some of the register group choices. In this function GDB wants to
treat all registers from a particular feature in a certain way. This
is fine for registers that GDB knows might be in that feature, but for
unknown registers the RISC-V parts of GDB have no easy way to figure
out which unknown registers exist, and what numbers they were
assigned.

We could figure this information out by probing the register
structures after calling tdesc_use_registers, but this would be
horrible, much better to have tdesc_use_registers tell the
architecture about unknown registers.

This is what this commit does. A new phase of tdesc_use_registers,
just before the unknown registers are assigned a number, we loop over
each tdesc_reg object, if it has not been assigned a number then we
figure out what number would be assigned and then call back into the
architecture passing the tdesc_feature, register name, and the
proposed register number.

The architecture is free to return the proposed register number, or it
can return a different number (which has a result identical to having
called tdesc_numbered_register). Alternatively the architecture can
return -1 to indicate the register should be numbered later.

After calling the callback for every tdesc_reg object any registers
still don't have a number assigned (because the architecture returned
-1), then a new register number is assigned, which might be different
from the proposed number that was suggested earlier.

This commit adds the general target-description parts of this
mechanism. No targets are currently using this code. The RISC-V
target will make use of this in the next commit.

There should be no user visible changes after this commit.

gdb/ChangeLog:

* target-descriptions.c (tdesc_use_registers): Add new parameter a
callback, use the callback (when not null) to help number unknown
registers.
* target-descriptions.h (tdesc_unknown_register_ftype): New typedef.
(tdesc_use_registers): Add extra parameter to declaration.

gdb/riscv: Improve support for matching against target descriptions

For the RISC-V target it is desirable if the three floating pointer
status CSRs fflags, frm, and fcsr can be placed into either the FPU
feature or the CSR feature. This allows different targets to build
the features in a way that better reflects their target.

The change to support this within GDB is fairly simple, so this is
done in this commit, and some tests added to check this new
functionality.

gdb/ChangeLog:

* riscv-tdep.c (value_of_riscv_user_reg): Moved to here from later
in the file.
(class riscv_pending_register_alias): Likewise.
(riscv_register_feature::register_info): Change 'required_p' field
to 'required', and change its type. Add 'check' member function.
(riscv_register_feature::register_info::check): Define new member
function.
(riscv_xreg_feature): Change initialisation of 'required' field.
(riscv_freg_feature): Likewise.
(riscv_virtual_feature): Likewise.
(riscv_csr_feature): Likewise.
(riscv_check_tdesc_feature): Take extra parameter, the csr
tdesc_feature, rewrite the function to use the new
riscv_register_feature::register_info::check function.
(riscv_gdbarch_init): Pass the csr tdesc_feature where needed.

gdb/testsuite/ChangeLog:

* gdb.arch/riscv-tdesc-loading-01.xml: New file.
* gdb.arch/riscv-tdesc-loading-02.xml: New file.
* gdb.arch/riscv-tdesc-loading-03.xml: New file.
* gdb.arch/riscv-tdesc-loading-04.xml: New file.
* gdb.arch/riscv-tdesc-loading.exp: New file.

gdb/riscv: Remove CSR feature file

There is currently a bug in the RISC-V CSR/FPU feature files. The
CSRs containing the FPU status registers are mentioned in both the FPU
feature file and the CSR feature file.

My original thinking when adding the FPU feature file was that it made
more sense to group the FPU status registers with the other FPU
state. This opened up the possibility of debugging very
simple (possibly simulator only) targets that had little more than CPU
and FPU available for GDB to access.

When I then added code to automatically generate the CSR XML file I
forgot to filter out the FPU status CSRs, so these registers were
mentioned twice.

Now for GDB's default RISC-V target descriptions this doesn't actually
matter. I did consider adding the CSRs to the default target
description, but in the end I didn't bother. The reasoning again was
simplicity; the default target description is only to be used when the
target doesn't supply its own description, and NOT supplying the CSRs
actually serves to encourage targets to supply an accurate
description. Combine this with the fact that the CSRs change from
revision to revision, sometimes in non-backward compatible ways, then
having a "default" set of CSRs just feels like a path to confusion and
complaints.

However, having a broken CSR XML file in the GDB source tree has had
one negative effect, QEMU has copied this file into its source tree,
and is using this as its description that it passes to GDB. That is
QEMU announces the FPU status registers twice, once in the FPU
feature, and once in the CSR feature.

This commit starts along the path back to sanity by deleting the
default CSR XML files from within GDB. These files were not used in
any way by current GDB, so there is absolutely no loss of
functionality with this change.

gdb/ChangeLog:

* features/Makefile: Remove all references to the deleted files
below.
* features/riscv/32bit-csr.c: Deleted.
* features/riscv/32bit-csr.xml: Deleted.
* features/riscv/64bit-csr.c: Deleted.
* features/riscv/64bit-csr.xml: Deleted.
* features/riscv/rebuild-csr-xml.sh: Deleted.

gdb/riscv: Take CSR names from target description

First, consider the RISC-V register $x1. This register has an alias
$ra. When GDB processes an incoming target description we allow the
target to use either register name to describe the target.

However, within GDB's UI we want to use the $ra alias in preference to
the $x1 architecture name.

To achieve this GDB overrides the tdesc_register_name callback with
riscv_register_name. In riscv_register_name we ensure that we always
return the preferred name, so in this case "ra".

To ensure the user can still access the register as $x1 if they want
to, when in riscv_check_tdesc_feature we spot that the target has
supplied the register, we add aliases for every name except the
preferred one, so in this case we add the alias "x1".

This scheme seems to work quite well, the targets have the flexibility
to be architecture focused if they wish (using x0 - x31) while GDB is
still using the ABI names ra, sp, gp, etc.

When this code was originally added there was an attempt made to
include the CSRs in the same scheme. At the time the CSRs only had
two names, one pulled from riscv-opc.h, and one generated in GDB that
had the pattern csr%d.

The idea was that if the remote targets description described the CSRs
as csr%d then GDB would rename these back to the real CSR name. This
code was only included because if followed the same pattern as the
x-regs and f-regs, not because I was actually aware of any target that
did this.

However, recent changes to add additional CSR aliases has made me
rethink the position here.

Lets consider the CSR $dscratch0. This register has an alias
'csr1970' (1970 is 0x7b2, which is the offset of the CSR register into
the CSR address space). However, this register was originally called
just 'dscratch', and so, after recent commits, this register also has
the alias 'dscratch'.

As the riscv-opc.h file calls this register 'dscratch0' GDB's
preferred name for this register is 'dscratch0'.

So, if the remote target description includes the register
'dscratch0', then GDB will add the aliases 'dscratch', and 'csr1970'.
In the UI GDB will describe the register as 'dscratch0', and all it
good.

The problem I see in this case is where the target describes the
register as 'dscratch'. In this case GDB will still spot the register
and add the aliases 'dscratch', and 'csr1970', GDB will then give the
register the preferred name 'dscratch0'.

I don't like this. For the CSRs I think that we should stick with the
naming scheme offered by the remote target description. As the RISC-V
specification evolves and CSR register names evolve, insisting on
referring to registers by the most up to date name makes it harder for
a target to provide a consistent target description for an older
version of the RISC-V architecture spec.

In this precise case the target offers 'dscratch', which is from an
older version of the RISC-V specification, the newer version of the
spec has two registers 'dscratch0' and 'dscratch1'. If we insist on
using 'dscratch0' it is then a little "weird" (or seems so to me) when
'dscratch1' is missing.

This patch makes a distinction between the x and f registers and the
other register sets. For x and f we still make use of the renaming
scheme, forcing GDB to prefer the ABI name. But after this patch the
CSR register group, and also the virtual register group, will always
prefer to use the name given in the target description, adding other
names as aliases, but not making any other name the preferred name.

gdb/ChangeLog:

* riscv-tdep.c (struct riscv_register_feature::register_info): Fix
whitespace error for declaration of names member variable.
(struct riscv_register_feature): Add new prefer_first_name member
variable, and fix whitespace error in declaration of registers.
(riscv_xreg_feature): Initialize prefer_first_name field.
(riscv_freg_feature): Likewise.
(riscv_virtual_feature): Likewise.
(riscv_csr_feature): Likewise.
(riscv_register_name): Expand on comments. Remove register name
modifications for CSR and virtual registers.

gdb/testsuite/ChangeLog:

* gdb.arch/riscv-tdesc-regs.exp: Extend test case.