LoongArch: Make align symbol be in same section with alignment directive

R_LARCH_ALIGN (psABI v2.30) requires a symbol index. The symbol is only
created at the first time to handle alignment directive. This means that
all other sections may use this symbol. If the section of this symbol is
discarded, there may be problems. Search it in its own section.

Remove elf_backend_data.is_rela_normal() function added at commit daeda14191c.

Co-authored-by: Jinyang He <hejinyang@loongson.cn>
Reported-by: WANG Xuerui <git@xen0n.name>
Link: https://lore.kernel.org/loongarch/2abbb633-a10e-71cc-a5e1-4d9e39074066@loongson.cn/T/#t

arm: testsuite: fix msdos line endings in tests

A couple of the tests in the testsuite were at some point in the past
committed with DOS-style CRLF line endings.  This potentially causes
email problems if the tests are touched in the middle of a large patch
series so convert them to standard Un*x line endings.

Automatic date update in version.in

gprofng: add hardware counters for AMD Zen4

ChangeLog
2024-06-01  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* common/hwctable.c: Add the hwc table for AMD Zen4.
* src/hwc_amd_zen4.h: New file.
* src/hwc_amd_zen3.h: Define _HWC_AMD_ZEN3_H.

Remove one call to can_box from TUI

This removes a call to can_box from
tui_source_window_base::show_source_content.  can_box will always
return true here.

Approved-By: Andrew Burgess <aburgess@redhat.com>

Fix deprecation text

I noticed one spot where deprecate_cmd is called with a second
argument that is not a command name.  This patch fixes the problem.

Regression tested on x86-64 Fedora 38.

Enable call of overloaded subscript operator from python

If you try to use the overloaded subscript operator of a class
in python, it fails like this:

(gdb) py print(gdb.parse_and_eval('b')[5])
Traceback (most recent call last):
  File "<string>", line 1, in <module>
gdb.error: Cannot subscript requested type.
Error while executing Python code.

This simply checks if such an operator exists, and calls it
instead, making this possible:

(gdb) py print(gdb.parse_and_eval('b')[5])
102 'f'

Approved-By: Tom Tromey <tom@tromey.com>

Allow calling of convenience functions with python

As mentioned in PR13326, currently when you try to call a
convenience function with python, you get this error:

(gdb) py print(gdb.convenience_variable("_isvoid")(3))
Traceback (most recent call last):
  File "<string>", line 1, in <module>
RuntimeError: Value is not callable (not TYPE_CODE_FUNC or TYPE_CODE_METHOD).
Error while executing Python code.

So this extends valpy_call to handle TYPE_CODE_INTERNAL_FUNCTION as
well, making this possible:

(gdb) py print(gdb.convenience_variable("_isvoid")(3))
0

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326
Approved-By: Tom Tromey <tom@tromey.com>

src-release.sh: Use -T0 for xz compression

Use parallel compression to create the xz archive.

On my machine (using 4 cores) this reduces the time to create
binutils-2.42.50.tar.xz from 1 minute 40 seconds to 56 seconds.

xz has supported -T0 since version 5.2.0 (released 2014-12-21).

[gdb/testsuite] Fix timeout in gdb.tui/resize-2.exp

When running test-case gdb.tui/resize-2.exp with taskset -c 0, I sometimes run
into:
...
tui disable^[[40;1H^M(gdb) PASS: $exp: tui disable
^M^[[K(gdb) FAIL: $exp: two prompt redisplays after resize (timeout)
...

The test-case does "Term::resize 24 80 0" while having the settings of an
earlier "Term::resize 40 90", so both dimensions change.

When TUI is enabled, we call Term::resize with wait_for_msg == 1, and the proc:
- calls stty to change one dimension,
- waits for the message (enabled by "maint set tui-resize-message on")
  confirming the resize has happened,
- calls stty to change the other dimension, and again
- waits for the message confirming the resize has happened.

Since TUI is disabled, we call Term::resize with wait_for_msg == 0 because the
message is not printed, so stty is called twice, and afterwards we check for
the results of the two resizes, which is the test that is failing.

The problem is that not waiting for a response after each stty call opens up
the possibility of the responses being merged.

Fix this by calling Term::resize twice, changing one dimension at a time, and
waiting for a single prompt redisplay after each one.

Tested on x86_64-linux.

Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
PR testsuite/31822
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31822

Automatic date update in version.in

Fix typo in tui-data.h

I noticed a typo in a comment in tui-data.h.

Automatic date update in version.in

Automatic date update in version.in

[gdb/testsuite] New test: gdb.base/errno.exp

Printing the value of 'errno' from GDB is sometimes problematic.  The
situation has improved in recent years, though there are still
scenarios for which "print errno" doesn't work.

The test, gdb.base/errno.exp, introduced by this commit, tests whether
or not GDB can print errno using a binary compiled in the following
different ways:

- default: no switches aside from -g (and whatever else is added by the
  testing framework)
- macros: macro info is included in the debuginfo; this is enabled by
  using -g3 when using gcc or clang
- static: statically linked binary
- static-macros: statically linked binary w/ macro definitions included
  in debuginfo
- pthreads: libpthread linked binary
- pthreads-macros: libpthread linked binary w/ macro definitions included
  in debuginfo
- pthreads-static: Statically linked against libpthread
- pthreads-static-macros: Statically linked against libpthread w/ macro
  definitions

For each of these, the test also creates a corefile, then loads the
corefile and attempts to print errno again.

Additionally, the test checks that a "masking" errno declared as a
local variable will print correctly.

On Linux, if the machine is missing glibc debuginfo (or you have
debuginfod disabled), it's likely you'll see:

    (gdb) print errno
    'errno' has unknown type; cast it to its declared type

But if you add a cast, the value of errno is often available:

    (gdb) print (int) errno
    $1 = 42

The test detects this situation along with several others and does
'setup_xfail' for tests that will almost certainly fail.  It could be
argued that some of these ought to be KFAILs due to deficiencies in
GDB, but I'm not entirely certain which, if any, are fixable yet.

On Fedora 39, without glibc debuginfo, there are no failures, but
I do see the following XFAILS:

XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: print errno
XFAIL: gdb.base/errno.exp: macros: print (int) errno
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: print errno
XFAIL: gdb.base/errno.exp: static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads: print errno
XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile

On Fedora 39, with glibc debug info, but without libc.a (for static
linking), there are 2 XFAILs, 2 UNSUPPORTED tests, and 4 UNTESTED
tests.

So, even when testing in less than ideal conditions, either due to lack
of glibc debuginfo or lack of a libc to link against to make a static
binary, there are no failures.

With glibc debuginfo installed, on Fedora 38, Fedora 39, Fedora 40,
Fedora rawhide (41), and Ubuntu 22.04.1 LTS, I see these XFAILs:

XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: print errno
XFAIL: gdb.base/errno.exp: static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile

On FreeBSD 13.1, the total number of XFAILs are fewer, and could be
even better still if it had debug info for glibc:

XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: print errno
XFAIL: gdb.base/errno.exp: macros: print (int) errno
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads: print errno
XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile

Starting with glibc-2.34, most of the pthreads library has been
incorporated into libc, so finding thread-local variables using
libthread_db is possible for several scenarios in which it previously
wasn't.  But, prior to this, accessing errno for the default scenario
was a problem.  This is borne out by running this new test on Fedora
34, which uses glibc-2.33:

XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: print (int) errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: print errno
XFAIL: gdb.base/errno.exp: static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile

In the v3 version of this test, Tom de Vries tested on openSUSE Leap
15.5 and found a number of cases which showed a FAIL instead of an
XFAIL.  The v4 version of this test fixed those problems.  On Leap
15.5, which uses glibc-2.31, with glibc debug info, I now see:

XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: print (int) errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile

On Leap 15.5, with glibc debuginfo missing, the results are a little
worse:

XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: print (int) errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: print errno
XFAIL: gdb.base/errno.exp: macros: print (int) errno
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads: print errno
XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile

The v5 version of this test fixed failures when testing with
check-read1.  (Thanks to Linaro CI for finding these.)  I revised the
regular expressions being used so that the failures were eliminated,
but the results mentioned above have not changed.

The v6 version of this test fixes some nits pointed out by both Tom
de Vries and Pedro Alves.  One of Pedro's suggestions was to rename the
test from check-errno.exp to errno.exp, so in v5, the name has
changed.  Tom also noticed that there were failures when using
--target_board=native-extended-gdbserver.  For v6, I've tested on 10
different Linux machines (F38, F39, F39 w/o glibc debuginfo, F39 w/o
static glibc, F40, rawhide, Ubuntu 22.04, Leap 15.5, Leap 15.5 w/o
glibc debuginfo, and Fedora 34) using "make check" and "make check-read1"
using target boards "unix", "native-extended-gdbserver", and
"native-gdbserver", with CC_FOR_TARGET set to both gcc and clang, for
a total of 12 distinct test runs on each machine.  I've also tested the
native-only cases on FreeBSD.  (Attempting to test against gdbserver
on FreeBSD resulted in hangs while running the test suite.)

The v7 version of this test simplifies the REs used in the uses of
gdb_test_multiple by adding -wrap and removing parts of the REs which
match the GDB prompt.  In cases where there was a leading '.*', those
were removed too.  Thanks to Pedro for explaining how to use -wrap.

So, bottom line, this test does not introduce any new failures on the
platforms on which I've tested, but the XFAILs are certainly unfortunate.
Some aren't fixable - e.g. when attempting to make a function call while
debugging a core file - but I think that some of them are.  I'm using
this new test case as a starting point for investigating problems with
printing errno.

Co-Authored-By: Jan Kratochvil
Approved-By: Tom de Vries <tdevries@suse.de>

aarch64, testsuite: avoid regexes in opcode field

Some dejagnu files use regexes rather than specific encodings. This
change replaces them with the explicit encodings we expect.

Tested against aarch64-unknown-linux-gnu and aarch64-none-elf.

gas, aarch64: Fixes in texi and tests following faminmax and lut changes

Making two cleanups that came out of the comments from my previous
patches:
1. Fixing `c-aarch64.texi` file so that the AArch64 architecture
   extensions are ordered alphabetically.
2. Fixing faminmax test cases so that they follow the existing test
   conventions.

Move dwarf2_per_bfd::index_addrmap to mapped_gdb_index

dwarf2_per_bfd::index_addrmap is only used by the .gdb_index reader,
so this field can be moved to mapped_gdb_index instead.  Then,
cooked_index_functions::find_per_cu can be removed in favor of a
method on the index object.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31821
Approved-By: Simon Marchi <simon.marchi@efficios.com>

aarch64: Add some DT_RELR ld tests

aarch64: Add DT_RELR support

The logic to decide if an input relocation for a symbol becomes a
particular kind of output relocation is one of the hard to maintain
parts of the bfd ld backend, since it is partially repeated across

 elfNN_aarch64_check_relocs (where dynamic relocations are counted per
 symbol and input section),

 elfNN_aarch64_late_size_sections (where relocation sections are sized
 and GOT offsets assigned),

 elfNN_aarch64_relocate_section (where most relocations are applied and
 output to a relocation section),

 elfNN_aarch64_finish_dynamic_symbol (where some of the GOT
 relocations are applied and output).

The DT_RELR support adds another layer to this complexity: after the
output relocation sections are sized, so all dynamic relocations are
accounted (in elfNN_aarch64_late_size_sections), we scan the symbols
and input relocations again to decide which ones become relative
relocations that can be packed. The sizes of the relocation sections
are updated accordingly. This logic must be consistent with the code
that applies the relocs later so each relative relocation is emitted
exactly once: either in .rela.* or packed in .relr.dyn.

Sizing of .relr.dyn is done via elfNN_aarch64_size_relative_relocs that
may be called repeatedly whenever the layout changes since an address
change can affect the size of the packed format. Then the final content
is emitted in elfNN_aarch64_finish_relative_relocs, that is called
after the layout is final and before relocations are applied and
emitted. These hooks are only called if DT_RELR is enabled.

We only pack relative relocs that are known to be aligned in the output
during .relr.dyn sizing, the potentially unaligned relative relocs are
emitted normally (in .rela.*, not packed), because the format requires
aligned addresses.

x86: reduce check_{byte,word,long,qword}_reg() overhead

These run after template matching. Therefore it is quite pointless for
them to check all operands, when operand sizes matching across operands
is already known. Exit the loops early in such cases.

In check_byte_reg() also drop a long-stale part of a comment.

gdb, amd64: remove unused forward declarations

These structs are not referenced anywhere anymore and seemed to have been
missed at some point when their usage was removed.

Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
Approved-By: Tom Tromey <tom@tromey.com>

gdb, doc: Fix AVX-512 documentation.

org.gnu.gdb.i386.avx512 adds k registers, but these aren't mentioned in the
docs yet.  Fix that.

In addition the documentation describes xmm registers with an `h`
(e.g. xmm16h).  I am assuming that we follow the register xml files here,
which don't have the h suffix.  So this removes that as well.

Approved-By: Eli Zaretskii <eliz@gnu.org>

gdb: remove unused includes in utils.h

Remove some includes reported as unused by clangd.  Add some includes in
other files that were previously relying on the transitive include.

Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e

Automatic date update in version.in

gdb: remove unused includes in symfile.c

Remove some includes reported as unused by clangd.

Change-Id: Iebd986eaf42409f1e526f09df0fcb0ce45c2fad6

gdb: remove unused includes in breakpoint.{c,h}

Remove some includes reported as unused by clangd.

Change-Id: I36d388bcff166f6baafa212f0bcbe8af64b2946d

Update binutils release documentation to include using the -z option when invoking src-release.sh

src-release.sh: Support zstd compression

.gitignore: ignore .vscode

Automatic date update in version.in

gdb/doc: don't have .pod targets separate to man page targets

While preparing the new release it was discovered that commit:

  commit 824083f34c222aa7419e2ea58e82d6f230d5f531
  Date:   Fri Apr 12 17:47:20 2024 +0100

      gdb/doc: use silent-rules.mk in the Makefile

was causing problems.  Given a release tar file, an attempt to build
and install GDB would give an error like this:

  [...]
    TEXI2POD gdb.pod
  cannot find GDBvn.texi at ../../../gdb-15.0.50.20240508/gdb/doc/../../etc/texi2pod.pl line 251, <GEN0> line 16.
  make[5]: *** [Makefile:663: gdb.pod] Error 2

The problem here is how the man pages are built, and how they are
distributed within a release.

Within the development (git) tree, the man page files are not part of
the source tree, these files are built as needed.  Within a release
tar file though, the man pages are included.  The idea being that a
user can build and install GDB, including getting the man pages,
without having to install the tools needed to generate the man pages.

The man pages are generated in a two step process.  First the .texi
file is processed with texi2pod to create a .pod file, then this .pod
file is processed to create the .1 or .5 man file.

Prior to the above commit these two steps were combined into a single
recipe, this meant that when a user performed a build/install from a
release tree all of the dependencies, as well as the final result,
were all present in the source tree, and so nothing needed to be
rebuilt.

However, the above commit split the two steps apart.  Now we had a
separate rule for building the .pod files, and the .1/.5 man page
files depended on the relevant .pod file.

As the .pod files are not shipped in a GDB release, this meant that
one of the dependencies of the man page files was now missing.  As a
result if a user tried to install from a release tree a rebuild of the
.pod files would be attempted, and if that succeeded then building the
man pages would follow that.

Unfortunately, building the .pod files would fail as the GDBvn.texi
file, though present in the source tree, was not present in the build
tree, which is where it is needed for the .pod file generation to
work.

To fix this, I propose merging the .pod creation and the .1/.5 man
page creation back into a single recipe.  Having these two steps split
is probably the "cleaner" solution, but makes it harder for us to
achieve our goal of shipping the prebuilt man page files.  I've added
a comment explaining what's going on (such a comment would have
prevented this mistake having been made in the first place).

One possibly weird thing here is that I have left both an
ECHO_TEXI2POD and a ECHO_TEXI2MAN in the rule $(MAN1S) and $(MAN5S)
recipes.  This is 100% not going to break anything, these just print
two different progress messages while executing the recipes, but I'm
not sure if this is considered poor style or not.  Maybe we're only
supposed to have a single ECHO_* per recipe?

Anyway, even if this is poor style, I figure it really is just a style
thing.  We can tweak this later as needed.  Otherwise, this commit
should fix the current issue blocking the next GDB release.

Approved-By: Tom Tromey <tom@tromey.com>

readelf: Use section names for displaying RELR relocs

In some cases using section names instead of symbol names for
displaying an address is more useful.

If the symbol falls outside the section where the address is
then likely it is not useful to display the address relative to.

And if symbols are stripped from a binary then printing the
section that contains the address is more useful than printing
<no sym>.

readelf: Fix symbol display for RELR relocs

Filter symbols before binary searching for the right symbol to display
for a given address, such that only displayable symbols are present and
at most one per address.

The current logic does not handle multiple symbols for the same address
well if some of them are empty, the selected symbol is not stable with
respect to an unrelated symbol table change and on aarch64 often mapping
symbols are displayed which is not useful.

Filtering solves these problems at the cost of a linear scan of the
sorted symbol table.

The heuristic to select the best symbol likely could be improved, this
patch aims to improve symbol display for RELR without complex logic
such that the output is useful and stable for ld tests.

x86/Intel: warn about undue mnemonic suffixes

Except for very few insns mnemonic suffixes aren't permitted in Intel
syntax. Warn about such for now, indicating that they will be outright
refused down the road.

While fiddling with testcases to address fallout, drop a few things
which should never have been tested as valid Intel syntax.

Also add a previously missing line to simd-suffix.d.

x86/Intel: SHLD/SHRD have dual meaning

Since we uniformly permit D suffixes in Intel mode whenever in AT&T mode
an L suffix may be used, we need to be consistent with this.

Take the easy route, despite that still leading to an anomaly which is
also visible from the new testcase:

shld eax, ecx, 1
shld eax, ecx, cl

can mean two things with APX: SHL with a D suffix in NDD EVEX encoding,
or the traditional SHLD in legacy encoding.

PR31796, Internal error in write_function_pdata at obj-coff-seh

PR31796 is the result of lack of aarch64 support in obj-coff-seh.c.
Nick fixed this with commit 73c8603c3f.  Make the seh support
consistently warn in future if some archictecture is missing, rather
than giving internal errors.

PR 31796
* config/obj-coff-seh.c (verify_target): New function.
(obj_coff_seh_handler, obj_coff_seh_endproc, obj_coff_seh_proc),
(obj_coff_seh_endprologue): Use it.

Automatic date update in version.in

ld: pru: Increase the default memory region sizes

The default memory region sizes for PRU were set somewhat arbitrarily to
the sizes of the most popular BeagleBone board with AM33x SoC.  But the
PRU toolchain documentation has always instructed to use SoC-specific
spec files to override the defaults and set the correct memory sizes [1].

The small default memory sizes can cause IMEM memory region overflow
even for simple printf("Hello world") programs, as usually done by
Autotools checks.  The stdio is simply too big to fit in 8K
instruction memory.  This can confuse the check and lead to wrong
feature selection during configure [2].

Fix by bumping the default DMEM and IMEM memory sizes.

There is no need to backport this patch.  Issue was caught with a
feature-rich newlib build used for daily CI.  The release builds of the
PRU toolchain use stripped newlib configuration, which does not overflow
the IMEM region, even for 8K.

[1] https://github.com/dinuxbg/gnuprumcu
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158

Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>

Make tui_win_info::make_window non-virtual

Nothing overrides tui_win_info::make_window, so remove the "virtual".
Tested by rebuilding.

gas, aarch64: Add SVE2 lut extension

Introduces instructions for the SVE2 lut extension for AArch64. They are documented in the following links:
* luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en
* luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en

These instructions use new SVE2 vector operands. They are called
SVE_Zm1_23_INDEX, SVE_Zm2_22_INDEX, and Zm3_12_INDEX and they have
1 bit, 2 bit, and 3 bit indices respectively.

The lsb and width of these new operands are the same as many existing
operands but the convention is to give different names to fields that
serve different purpose so we introduced new fields in aarch64-opc.c
and aarch64-opc.h.

We made a design choice for the second operand of the halfword variant of
luti4 with two register tables. We could have either defined a new operand,
like SVE_Znx2, or we could have use the existing operand SVE_ZnxN. With
the new operand, we would need to implement constraints on register
lists based on either operand or opcode flag. With existing operand, we
could just existing constraint checks using opcode flag. We chose
the second approach and went with SVE_ZnxN and added opcode flag to
enforce lengths of vector register list operands. This way, we can reuse
the existing constraint check logic.

gas, aarch64: Add AdvSIMD lut extension

Introduces instructions for the Advanced SIMD lut extension for AArch64. They are documented in the following links:
* luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en
* luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en

These instructions needed definition of some new operands. We will first
discuss operands for the third operand of the instructions and then
discuss a vector register list operand needed for the second operand.

The third operands are vectors with bit indices and without type
qualifiers. They are called Em_INDEX1_14, Em_INDEX2_13, and Em_INDEX3_12
and they have 1 bit, 2 bit, and 3 bit indices respectively. For these
new operands, we defined new parsing case branch. The lsb and width of
these operands are the same as many existing but the convention is to
give different names to fields that serve different purpose so we
introduced new fields in aarch64-opc.c and aarch64-opc.h for these new
operands.

For the second operand of these instructions, we introduced a new
operand called LVn_LUT. This represents a vector register list with
stride 1. We defined new inserter and extractor for this new operand and
it is encoded in FLD_Rn. We are enforcing the number of registers in the
reglist using opcode flag rather than operand flag as this is what other
SIMD vector register list operands are doing. The disassembly also uses
opcode flag to print the correct number of registers.

Use bool in thread_events

This changes target_ops::thread_events and target_thread_events to use
'bool'.  The callers were already doing this.

Tested by rebuilding.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Fix typo in assembler documentation

Fix: internal error in write_function_pdata at obj-coff-seh

  PR 31796

Updated Spanish translation for the BFD sub-directory.

opcodes: add a .gitattributes file for aarch64 autogenerated file exceptions

The autogenerated files in opcodes use spaces for indentation.
Changing that would be a lot of work to little benefit, so add a local
override to the white-space rules, so patches apply cleanly.

Add new ELF section and segment types to readelf.

RISC-V: Fix U insn; replace opcode6 with opcode7 in gas/doc/c-riscv.texi

The type U RISC-V instruction format in gas/doc/c-riscv.texi shows the
bit arrangement of the simm20 immediate that belongs to the J type;
It should be just `simm20[19:0]`.  The current behavior of `gas` matches
the proposed documentation change.

Additionally, the opcode is called `opcode6` despite of having 7 bits.
Rename it to `opcode7`.

gas/
* doc/c-riscv.texi: Fix U type, and replace opcode6 with opcode7.

Automatic date update in version.in

Re-run make-target-delegates.py

I re-ran make-target-delegates.py and discovered that the tree was out
of sync.  This patch corrects the problem.

RISC-V: Fixed overwritten IRELATIVE relocs in the .rel.iplt for data reloc.

This was originally reported by Hau Hsu <hau.hsu@sifive.com>.

Similar to commit 51a8a7c2e3cc0730831963651a55d23d1fae624d

We shouldn't use riscv_elf_append_rela to add dynamic relocs into .rela.iplt
in the riscv_elf_relocate_section when handling ifunc data reloc R_RISCV_32/64.
This just like what did in the riscv_elf_finish_dynamic_symbol.

bfd/
* elfnn-riscv.c (riscv_elf_relocate_section): We shouldn't use
riscv_elf_append_rela to add dynamic relocs into .rela.iplt in the
riscv_elf_relocate_section when handling ifunc data reloc.
ld/
* testsuite/ld-riscv-elf/ifunc-overwrite.s: Updated and renamed.
* testsuite/ld-riscv-elf/ifunc-overwrite-exe.rd: Likewise.
* testsuite/ld-riscv-elf/ifunc-overwrite-pic.rd: Likewise.
* testsuite/ld-riscv-elf/ifunc-overwrite-pie.rd: Likewise.
* testsuite/ld-riscv-elf/ifunc-overwrite.d: Renamed.

RISC-V: Segment fault for kernel purgatory when linking.

This was originally reported by Ard Biesheuvel <ardb@kernel.org>.

The followings are reproduce steps,
https://lore.kernel.org/all/202404260640.9GQVTmrw-lkp@intel.com/T/#u

The segment fault happens in the riscv_elf_finish_dynamic_sections when the
output got section is an ABS.  Refer to MIPS code, they added an extra
bfd_is_abs_section check to avoid ABS got, so this seems the right and easier
way to go in the short-term.

bfd/
* elfnn-riscv.c (riscv_elf_finish_dynamic_sections): Set sh_entsize
and fill the got entries only when the got isn't an ABS section, and
the size of got is larger than zero.  The similar goes for gotplt,
except we already reported error when the gotplt is an ABS.

LoongArch: Fix relaxation overflow caused by ld -z separate-code

ld -z separate-code let .text and .rodata in two different but read only
segment. If the symbol and pc in two segment, the offset from pc to
symbol need to consider segment alignment.

Add a function 'loongarch_two_sections_in_same_segment' to determine
whether two sections are in the same segment.

Automatic date update in version.in

Update gdb/NEWS after GDB 15 branch creation.

This commit a new section for the next release branch, and renames
the section of the current branch, now that it has been cut.

Bump version to 16.0.50.DATE-git.

Now that the GDB 15 branch has been created,
this commit bumps the version number in gdb/version.in to
16.0.50.DATE-git

For the record, the GDB 15 branch was created
from commit 3a624d9f1c5ccd8cefdd5b7ef12b41513f9006cd.

Also, as a result of the version bump, the following changes
have been made in gdb/testsuite:

* gdb.base/default.exp: Change $_gdb_major to 16.

Automatic date update in version.in

ld: Document -pie -Ttext-segment=ORG generates ET_EXEC

This is the v2 patch I am checking in.

H.J.

Automatic date update in version.in

Re: LoongArch: gas: Adjust DWARF CIE alignment factors

Adjust the gas testsuite to suit commit de203ed568f6.

* testsuite/gas/loongarch/relax-cfi-fde-DW_CFA_advance_loc.d:
Expect data alignment of -8.  Tidy.

gas: extend \+ support to .irp / .irpc

PR gas/31752

These are effectively macro-like, without any separate macro definition.
They already support \@, so they would better also support \+. This
allows, where desired, to get away without maintaining an explicit count
variable in source code.

With this the recently introduced testcase doesn't need any xfails
anymore.

gas: adjust handling of quotes for .irpc

The present handling of inner double quotes can lead to very strange
diagnostics. Follow one of the two possible interpretations of the doc:
@dots{} referring to possibly multiple white space separated
@var{values}, each of which may be quoted. The original implementation,
prior to 465e5617233f ("PR gas/3856"), hints at the other possible
interpretation: When quoted there's only a single @var{values}, with
inner quotes taken as ordinary characters. That, however, seems overall
less useful to me.

While touching the documentation, mirror the (inverse) spelling
correction (@section line inconsistent with actual description) to .irp
as well.

x86: simplify VexVVVV_SRC2 handling for the XOP case

As already suggested during review, rather than having an extra
conditional in build_modrm_byte() (a code path used for quite a few
more insns, including even certain GPR ones), adjust the attribute in
the installed template to properly describe things with operands
swapped.

x86: simplify / consolidate check_{word,long,qword}_reg()

These run after template matching. Therefore operands are already known
to match the template in use. With the loop bodies skipping anything not
a GPR in the actual operands, there's therefore no need to check the
template's operand type for permitting Reg or Accum.

At the same time bring the three functions in sync for the "byte" part
of the logic, as far as checking the template for other sizes (qword
specifically) goes. Plus drop a stale comment from check_qword_reg(),
when all three are now behaving the same in this regard.

x86: correct VCVT{,U}SI2SD

Properly reject inappropriate suffixes (No_lSuf / No_qSuf mistakenly
omitted by cf665fee1d6c ["x86: re-work AVX512 embedded rounding / SAE"]),
to avoid emitting bad or arbitrarily guessed instructions. Interestingly
check_{long,qword}_suffix() don't help here, which perhaps is another
indication that the way they work right now isn't quite appropriate.

Sadly correcting just the templates breaks operand ambiguity detection,
since so far that worked from a single template permitting more than one
suffix. Here we have ambiguity though which can now be noticed only when
taking all (matching) templates together. Therefore we need to determine
further matching templates (see code comments for constraints), to then
accumulate permitted suffixes across all of them.

[gdb/testsuite] Add PR26286 kfail in gdb.threads/attach-many-short-lived-threads.exp

When running test-case gdb.threads/attach-many-short-lived-threads.exp, I run
regularly into PR26286:
...
(gdb) continue^M
Continuing.^M
[LWP ... exited]^M
  ...
[LWP ... exited]^M
^M
Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M
The program no longer exists.^M
(gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \
  break at break_fn: 1
...

Add a kfail for this, such that we have:
...
(gdb) KFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \
  break at break_fn: 1 (PRMS: threads/26286)
...

Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Tested on x86_64-linux.

Automatic date update in version.in

gdb, testsuite: Fix return value in gdb.base/foll-fork.exp

In a remote testing setup, I saw this error:

~~~
(gdb) FAIL: gdb.base/foll-fork.exp: check_fork_catchpoints: runto: run to main
ERROR: tcl error sourcing gdb/gdb/testsuite/gdb.base/foll-fork.exp.
ERROR: expected boolean value but got ""
    while executing
"if { ![check_fork_catchpoints] } {
    untested "follow-fork not supported"
    return
}"
    (file "gdb/gdb/testsuite/gdb.base/foll-fork.exp" line 434)
    invoked from within
"source gdb/gdb/testsuite/gdb.base/foll-fork.exp"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 source gdb/gdb/testsuite/gdb.base/foll-fork.exp"
    invoked from within
"catch "uplevel #0 source $test_file_name""
Remote debugging from host 172.0.1.3, port 37766
Killing process(es): 1171
Quit
~~~

The actual reason for this were some connection problems. Though the
function check_fork_catchpoints shouldn't return an empty string, especially
as it promises to always return 0 or 1. Fix that.

Approved-By: Tom Tromey <tom@tromey.com>

gdb/testsuite: Restore libc_has_debug_info's less strict behaviour

The code that was factored out from gdb.base/relativedebug.exp assumed that
libc has debug info and only determined that it doesn't if it saw a specific
message from GDB to that effect.  In the process of factoring it into a
require predicate, I made it stricter by trying to make a specific
determination of whether or not debug info is available.

Pedro noticed that "It'll disable the testcase on systems that link with
their libc statically (even if has debug info), or systems that name their
libc something else."  Which is something I hadn't considered.

This patch returns libc_has_debug_info to the original behaviour.

Also, remove a verbose message that is redundant with the $message
variable.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31700
Approved-By: Tom Tromey <tom@tromey.com>

Automatic date update in version.in

libctf testsuite compilation failure

* testsuite/libctf-regression/open-error-free.c (main): Correct
format length modifier.

Default dwarf_synchronous to true

Unfortunately the background DWARF reading series introduced a number
of races, as repored by thread sanitizer.  This patch changes gdb to
disable this feature for the time being -- in particular for the gdb
15 release.

I've filed a bug and linked all the known races to it.  Once those are
fixed we can re-enable this feature by default.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31751

restore build with --enable-maintainer-mode

A build with --enable-maintainer-mode is currently failing with:

make[4]: *** No rule to make target '<SRC>/gas/config/te-ia64aix.h',
 needed by '<SRC>/gas/po/gas.pot'.  Stop.
make[4]: Leaving directory '<$OBJ>/gas/po'
make[3]: *** [Makefile:1695: all-recursive] Error 1
...

As config/te-ia64aix.h is now removed, remove the corresponding fragment
from the makefile.

gas/
        * Makefile.am: Remove config/te-ia64aix.h.
        * Makefile.in: Regenerate.
        * po/POTFILES.in: Regenerate.

aarch64: fix incorrect encoding for system register pmsdsfr_el1

This patch fixes a mistake in the encoding of the system register
pmsdsfr_el1.

Reference:
https://developer.arm.com/documentation/ddi0601/2022-09/AArch64-Registers/PMSDSFR-EL1--Sampling-Data-Source-Filter-Register?lang=en

Support APX zero-upper

This patch is to enable ZU for IMUL (opcodes 0x69 and 0x6B) and SETcc.
Since the spec only recommends one form of setzu, I won't be adding
set<cc>reg32/reg64 support in this patch.

gas/ChangeLog:

        * config/tc-i386.c (build_apx_evex_prefix): Handle ZU.
        * testsuite/gas/i386/x86-64.exp: Added new tests for ZU.
        * testsuite/gas/i386/x86-64.exp: Added new tests for ZU.
        * testsuite/gas/i386/x86-64-apx-zu-intel.d: New test.
        * testsuite/gas/i386/x86-64-apx-zu-inval.l: Ditto.
        * testsuite/gas/i386/x86-64-apx-zu-inval.s: Ditto.
        * testsuite/gas/i386/x86-64-apx-zu.d: Ditto.
        * testsuite/gas/i386/x86-64-apx-zu.s: Ditto.

opcodes/ChangeLog:

        * i386-dis-evex-prefix.h: Handle PREFIX_EVEX_MAP4_40 ~
        PREFIX_EVEX_MAP4_4F.
        * i386-dis-evex.h: Ditto.
        * i386-dis.c (struct dis386): Add new micro 'ZU'.
        (putop): Handle %ZU.
        * i386-gen.c: Added ZU.
        * i386-opc.h: Ditto.
        * i386-opc.tbl: Added new templates to support ZU.

X86: Remove "i.rex" to eliminate extra conditional branch

Resulting code will do better without the extra conditional branch.
Remove "i.rex" to eliminate extra conditional branch.

gas/ChangeLog:

        * config/tc-i386.c (establish_rex): Remove i.rex.

gprofng: use StringBuilder to create long messages

ChangeLog
2024-05-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/collctrl.cc: Use StringBuilder to create messages.
Remove unused variables and arrays.
* src/collctrl.h: Remove unused variables.

gprofng: Remove hardware counter tables for unsupported hardware (Sparc)

ChangeLog
2024-05-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/31123
* common/hwctable.c: Remove hardware counter tables for Sparc machines.

gprofng: remove memset() in libcollector

ChangeLog
2024-05-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* libcollector/collector.c: Use static initialization instead of memset.
* libcollector/dispatcher.c: Likewise.
* libcollector/hwprofile.c: Likewise.
* libcollector/jprofile.c: Likewise.
* libcollector/profile.c: Likewise.
* libcollector/synctrace.c: Likewise.

Add check for 8-bit old registers in EVEX format

Since APX supports EVEX from legacy instructions, we need to check
the 8-bit old registers in EVEX format. And add test cases for it.

gas/ChangeLog:

        * config/tc-i386.c (md_assemble): Add invalid check for old byte
        registers in EVEX format.
        * testsuite/gas/i386/x86-64-apx-inval.l: Add new test.
        * testsuite/gas/i386/x86-64-apx-inval.s: Ditto.

x86: Split REX/REX2 old registers judgment.

Split "REX/REX2 old register checking" and "add empty rex prefix"
into two separate branches.

gas/ChangeLog:

        * config/tc-i386.c (establish_rex): Split the judgments.

Automatic date update in version.in

gas: ginsn: remove unnecessary buffer allocation and free

A previous commit 80ec235 fixed the memory leaks, but brought to light
that the code should ideally make consistent use of snprintf and not
allocate/free more buffers than necessary.

gas/
* ginsn.c (ginsn_dst_print): Use snprintf consistently.

aarch64: Fix the hyphenated disassembly comment.

This patch fixes the following comment.

-  /* The hyphenated form is preferred for disassembly if there are
-     more than two registers in the list, and the register numbers
      are monotonically increasing in increments of one.  */

+  /* The hyphenated form is preferred for disassembly if there is
+     more than one register in the list, and the register numbers
      are monotonically increasing in increments of one.  */

Clarify documentation for pretty_printer.child

An Ada pretty-printer had a bug where its 'child' method returned a
gdb.Value rather than a tuple.  Kévin suggested that the documentation
for this method could be improved to clarify this.

Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
Approved-By: Eli Zaretskii <eliz@gnu.org>

gas: drop remnants of ia64-*-aix*

With BFD not supporting that target anymore, GAS can't possibly support
it either.

ld: silence makeinfo warnings

Older tool versions (4.12 in my case) demand . or , after @xref{};
arrange for this to be the case.

include, libctf: improve documentation

Some review comments came in after I pushed the last lot of ctf-api.h
comment improvements.  They were good, so I've incorporated them.
Mostly: better _next iterator usage info, better info on ctf_*open
functions, and better info on ctf_type_aname and ctf_type_name_raw.

include/
* ctf-api.h: improve documentation.

Automatic date update in version.in

gdb: Fix Windows build after #include shuffle

Without this patch, the build chokes on:

    ../../src/gdb/windows-nat.c:384:21: error: field 'm_debug_event_pending' has incomplete type 'std::atomic<bool>'
      384 |   std::atomic<bool> m_debug_event_pending { false };
          |                     ^~~~~~~~~~~~~~~~~~~~~
    In file included from […gcc tree…]/include/c++/13.2.1/bits/shared_ptr_atomic.h:33,
                     from […gcc tree…]/include/c++/13.2.1/memory:81,
                     from ../../src/gdb/../gdbsupport/gdb_unique_ptr.h:23,
                     from ../../src/gdb/../gdbsupport/common-utils.h:26,
                     from ../../src/gdb/../gdbsupport/common-defs.h:199,
                     from ./../../src/gdb/defs.h:26,
                     from <command-line>:
    […gcc tree…]/include/c++/13.2.1/bits/atomic_base.h:174:12: note: declaration of 'struct std::atomic<bool>'
      174 |     struct atomic;
          |            ^~~~~~
    make.exe[2]: *** [Makefile:1947: windows-nat.o] Error 1

Presumably windows-nat.c relied on objfiles.h including <atomic>,
which was undone in 2024-05-16 "gdb: remove unused includes in
objfiles.{c,h}" (f617661c110).

readelf: add pretty printing for FDO Dlopen Metadata note

Add extra files found in etc/ sub-directory to ETC_SUPPORT in src-release.sh

  PR 31726

[gdb/testsuite] Fix can_spawn_for_attach_1 consistency check

When running test-case gdb.testsuite/gdb-caching-proc-consistency.exp with
target board native-gdbserver, we run into:
...
(gdb) ERROR: tcl error sourcing gdb.testsuite/gdb-caching-proc-consistency.exp.
ERROR: gdbserver does not support attach 4827 without extended-remote
    while executing
"error "gdbserver does not support $command without extended-remote""
    (procedure "gdb_test_multiple" line 51)
    invoked from within
"gdb_test_multiple "attach $test_pid" "can spawn for attach" {
        -re -wrap "$attaching_re\r\n.*ptrace: Operation not permitted\\." {
            # Not permitte..."
    (procedure "gdb_real__can_spawn_for_attach_1" line 27)
    invoked from within
"gdb_real__can_spawn_for_attach_1"
...

The problem is that:
- can_spawn_for_attach_1 is a helper function for can_spawn_for_attach,
  designed to be called only from that function, and
- can_spawn_for_attach_1 is a gdb_caching_proc, and consequently
  test-case gdb.testsuite/gdb-caching-proc-consistency.exp calls
  can_spawn_for_attach_1 directly.

Fix this by copying the early-outs from can_spawn_for_attach to
can_spawn_for_attach_1.

Tested on x86_64-linux.

Reported-By: Simon Marchi <simark@simark.ca>
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

aarch64: Add support for the fpmr system register

Include .rodata size in avr-objdump -P mem-usage.

  PR 31687

Let avr-objdump show .note.gnu.avr.deviceinfo

  PR 31704

RISC-V: PR31733, Change initial CFI operation from DW_CFA_def_cfa_register to DW_CFA_def_cfa

The DWARF specification (especially, DWARF4 and 5 [1,2]) states that
DW_CFA_def_cfa_register cannot be used as the first CFI operation.
It said DW_CFA_def_cfa_register as follows:

  ... This operation is valid only if the current CFA rule is defined
  to use a register and offset.

So, DW_CFA_def_cfa_register can be used after that other definition
operation such as DW_CFA_def_cfa is called. However, the current gas
code emits DW_CFA_def_cfa_register as an initial CFI operation for RISCV.

In the libgcc, the unwinding function does not care about it, so it can
unwind the call stack. However, on the third party library such as
libunwindstack in Android, it causes a fatal error.

This patch changes the initial CFI operation to DW_CFA_def_cfa with
offset 0. It works as same as the previous one, but it does not have
any limitation so it satisfies the DWARF spec. This change resolves
the compatibility issue while preserving the original behaviour.

[1] DWARF4 specification, https://dwarfstd.org/doc/DWARF4.pdf
[2] DWARF5 specification, https://dwarfstd.org/doc/DWARF5.pdf

Signed-off-by: Sung-hun Kim <sfoon.kim@samsung.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Nelson Chu <nelson@rivosinc.com>
gas/
PR 31733
config/tc-riscv.c (riscv_cfi_frame_initial_instructions): Use
DW_CFA_def_cfa rather than DW_CFA_def_cfa_register.

Automatic date update in version.in

Automatic date update in version.in