aarch64: Fix error in THE system register checking

The erroneous omission of a "reg_value == " in the THE system register
encoding check added in [1] led to an error which was not picked up in
GCC but which was flagged in Clang due to its use of
[-Werror,-Wconstant-logical-operand] check.  Together with this fix we
add a new test for the THE registers to pick up their illegal use,
adding an extra and important layer of validation.

Furthermore, in separating system register from instruction
implementation (with which only the former was of concern in the cited
patch), additions made to `aarch64-tbl.h' are rolled back so
that these can be added later when adding THE instructions to the
codebase, a more natural place for these changes.

[1] https://sourceware.org/pipermail/binutils/2023-November/130314.html

opcodes/ChangeLog:

* aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Fix typo.
* aarch64-tbl.h (THE): Remove.
 (aarch64_feature_set aarch64_feature_the): Likewise.

gas/ChangeLog:

* testsuite/gas/aarch64/illegal-sysreg-8.l: Add tests for THE
system registers.
* testsuite/gas/aarch64/illegal-sysreg-8.s: Likewise.

x86: rework UWRMSR operand swapping

As indicated during review already, doing the swapping early is overall
cheaper than doing it only after operand matching.

x86: do away with is_evex_encoding()

As we have grown more uses of it, it becomes increasingly more desirable
to replace it by a simpler check. Have i386-gen do at build time what so
far was done at runtime: Deal with templates indicating EVEX-encoding by
other than the EVex attribute, and set that to "dynamic" in such cases.

This then allows simplifying a number of other conditionals as well.

x86: split insn templates' CPU field

Right now the opcode table has entries with ISA restrictions of the form
FEAT1|FEAT2, the meaning of which depends on context and requires
special treatment in tc-i386.c: Sometimes this means "both features
requires", whereas originally it was intended to solely mean "all of
these features required". Split the field, with the original one
regaining its original meaning. The new field now truly means "any of
these". The combination of both fields is still and &&-type check, i.e.
(all of these) && (any of these). In the opcode table more involved
combinations of features then also need expressing this way: "all"
entities first, follow by "any" entities enclosed in parentheses, e.g.
x64&(AVX|AVX512F). If the "all" part is empty, parentheses may not be
added around the "any" part (unless parsing logic was further relaxed).

Note that this way AVX512VL no longer needs as much special treatment,
and hence templates previously using AVX512F|AVX512VL are switched to
just AVX512VL.

Note further that this requires FMA handling as resulting from
da0784f961d8 ("x86: fold FMA VEX and EVEX templates") to be slightly
re-done: FMA now becomes more similar to AVX and AVX2.

x86: Cpu64 handling improvements

First of all we want to also accumulate its reverse dependencies, such
that we can use them in cpu_flags_match(). This is in particular in
preparation of APX additions, such that e.g. BMI VEX-encoding templates
can become combined VEX/EVEX ones.

Once we have the reverse dependencies, we can further leverage them to
omit explicit "&x64" from any insn templates dealing with 64-bit-mode-
only ISA extensions. Besides helping readability for several insn
templates we already have, this will also help with what is going to be
added for APX (as all of the new templates would otherwise need to have
"&x64").

Note that rather than leaving a meaningless CPU_64_FLAGS (which is
unused anyway), its emitting is now also suppressed.

x86: Intel Core processors do not support CMPXCHG16B

This being a 64-bit-only instruction (see also i386-opc.tbl) it cannot
possibly be supported by CPUs not supporting 64-bit mode.

Automatic date update in version.in

rs6000, Fix test gdb.base/store.exp

The test currently fails for IEEE 128-bit floating point types.  PowerPC
supports the IBM double 128-bit floating point format and IEEE 128-bit
format.  The IBM double 128-bit floating point format uses two 64-bit
floating point registers to store the 128-bit value.  The IEEE 128-bit
floating point format stores the value in a single 128-bit vector-scalar
register (vsr).

The various floating point values, 32-bit float, 64-bit double, IBM double
128-bit float and IEEE 128-bit floating point numbers are all mapped to the
DWARF fpr numbers.  The issue is the IEEE 128-bit floating point values are
actually stored in a vsr not the fprs.  This patch changes the register
mapping for the vsrs from the fpr to the vsr registers so the value is
properly accessed by GDB.  The functions rs6000_linux_register_to_value,
rs6000_linux_value_to_register, rs6000_linux_value_from_register check if
the value is an IEEE 128-bit floating point value and adjust the register
number as needed.  The test in function rs6000_convert_register_p is fixed
so it is only true for floating point values.

This patch fixes three regression tests in gdb.base/store.exp.

The patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 LE
with no regressions.

rs6000, Fix Linux DWARF register mapping

Overview of issues fixed by the patch.

The primary issue this patch fixes is the DWARF register mapping for
Linux.  The changes in ppc-linux-tdep.c fix the DWARF register mapping
issues.  The register mapping issue is responsible for two of the
five regression bugs seen in gdb.base/store.exp.

Once the register mapping was fixed, an underlying issue with the unwinding
of the signal trampoline in common-code in ifrun.c was found.  This
underlying bug is best described by Ulrich in the following description.

  The unwinder bug shows up on platforms where the kernel uses a trampoline
  to dispatch "calls to" the signal handler (not just *returns from* the
  signal handler).  Many platforms use a trampoline for signal return, and
  that is working fine, but the only platform I'm (Ulrich) aware of that
  uses a trampoline for signal handler calls is (recent kernels for)
  PowerPC.  I believe the rationale for using a trampoline here
  is to improve performance by avoiding unbalancing of the
  branch predictor's call/return stack.

  However, on PowerPC the bug is dormant as well as it is hidden
  by *another* bug that prevents correct unwinding out of the
  signal trampoline.  This is because the custom CFI for the
  trampoline uses a register number (VSCR) that is not ever used
  by compiler-generated CFI, and that particular register is
  mapped to an invalid number by the current PowerPC DWARF mapper.

The underlying unwinder bug is exposed by the "new" regression failures
in gdb.base/sigstep.exp.  These failures were previously masked by
the fact that GDB was not seeing a valid frame when it tried to unwind
the frames.  The sigstep.exp test is specifically testing stepping into
a signal handler.  With the correct DWARF register mapping in place,
specifically the VSCR mapping, the signal trampoline code now unwinds to a
valid frame exposing the pre-existing bug in how the signal handler on
PowerPC works.  The one line change infrun.c fixes the exiting bug in
the common-code for platforms that use a trampoline to dispatch calls
to the signal handler by not stopping in the SIGTRAMP_FRAME.

Detailed description of the DWARF register mapping fix.

The PowerPC DWARF register mapping is the same for the .eh_frame and
.debug_frame on Linux.  PowerPC uses different mapping for .eh_frame and
.debug_frame on other operating systems.  The current GDB support for
mapping the DWARF registers in rs6000_linux_dwarf2_reg_to_regnum and
rs6000_adjust_frame_regnum file gdb/rs6000-tdep.c is not correct for Linux.
The files have some legacy mappings for spe_acc, spefscr, EV which was
removed from GCC in 2017.

This patch adds a two new functions rs6000_linux_dwarf2_reg_to_regnum,
and rs6000_linux_adjust_frame_regnum in file gdb/ppc-linux-tdep.c to handle
the DWARF register mappings on Linux.  Function
rs6000_linux_dwarf2_reg_to_regnum is installed for both gdb_dwarf_to_regnum
and gdbarch_stab_reg_to_regnum since the mappings are the same.

The ppc_linux_init_abi function in gdb/ppc-linux-tdep.c is updated to
call set_gdbarch_dwarf2_reg_to_regnum map the new function
rs6000_linux_dwarf2_reg_to_regnum for the architecture.  Similarly,
dwarf2_frame_set_adjust_regnum is called to map
rs6000_linux_adjust_frame_regnum into the architecture.

Additional detail on the signal handling fix.

The specific sequence of events for handling a signal on most
architectures is as follows:

  1) Some code is running when a signal arrives.
  2) The kernel handles the signal and dispatches to the handler.
    ...

However on PowerPC the sequence of events is:

  1) Some code is running when a signal arrives.
  2) The kernel handles the signal and dispatches to the trampoline.
  3) The trampoline performs a normal function call to the handler.
      ...

We want the "nexti" to step into, not over, signal handlers invoked by
the kernel.  This is the case for most platforms as the kernel puts a
signal trampoline frame onto the stack to handle proper return after the
handler.  However, on some platforms such as PowerPC, the kernel actually
uses a trampoline to handle *invocation* of the handler.  We do not
want GDB to stop in the SIGTRAMP_FRAME.  The issue is fixed in function
process_event_stop_test by adding a check that the frame is not a
SIGTRAMP_FRAME to the if statement to stop in a subroutine call.  This
prevents GDB from erroneously detecting the trampoline invocation as a
subroutine call.

This patch fixes two regression test failures in gdb.base/store.exp.

The patch then fixes an exposed, dormant, signal handling issue that
is exposed in the signal handling test gdb.base/sigstep.exp.

The patch has been tested on Power 8 LE/BE, Power 9 LE/BE, Power 10 with
no new regressions.  Note, only two of the five failures in store.exp
are fixed.  The remaining three failures are fixed in a following
patch.

gdb: call update_thread_list after completing an inferior call

I noticed that if GDB is using a remote or extended-remote target,
then, if an inferior call caused a new thread to appear, or for an
existing thread to exit, then these events are not reported to the
user.

The problem is that for these targets GDB relies on a call to
update_thread_list to learn about changes to the inferior's thread
list.

If GDB doesn't pass through the normal stop code then GDB will not
call update_thread_list, and so will not report changes in the thread
list.

This commit adds an additional update_thread_list call, after which
thread events are correctly reported.

gdb: call update_thread_list for $_inferior_thread_count function

I noticed that sometimes the value returned by $_inferior_thread_count
can become out of sync with the actual thread count of the inferior,
and will disagree with the number of threads reported by 'info
threads'.  This commit fixes this issue.

The cause of the problem is that 'info threads' includes a call to
update_thread_list, this can be seen in print_thread_info_1 in
thread.c, while $_inferior_thread_count doesn't include a similar
call, see the function inferior_thread_count_make_value also in
thread.c.

Of course, this is only a problem when GDB is running on a target that
relies on update_thread_list calls to learn about new threads,
e.g. remote or extended-remote targets.  Native targets generally
learn about new threads as soon as they appear and will not have this
problem.

I ran into this issue when writing a test for the next commit which
uses inferior function calls to add an remove threads from an
inferior.  But for testing I've made use of non-stop mode and
asynchronous inferior execution; by reading the inferior state I can
know when a new thread has been created, at which point I can print
$_inferior_thread_count while the inferior is still running.  This is
important, if I stop the inferior then GDB will pass through an
update_thread_list call in the normal stop code, which will
synchronise the thread list, after which $_inferior_thread_count will
report the correct value.

With this change in place $_inferior_thread_count is now correct.

gdb: add a custom command completer for disassemble command

Add a new command completer function for the disassemble command.
There are two things that this completion function changes.  First,
after the previous commit, the new function calls skip_over_slash_fmt,
which means that hitting tab after entering a /OPT flag now inserts a
space ready to start typing the address to disassemble at:

  (gdb) disassemble /r<TAB>
  (gdb) disassemble /r <CURSOR>

But also, we now get symbol completion after a /OPT option set,
previously this would do nothing:

  (gdb) disassemble /r mai<TAB>

But now:

  (gdb) disassemble /r mai<TAB>
  (gdb) disassemble /r main <CURSOR>

Which was my main motivation for working on this commit.

However, I have made a second change in the completion function.
Currently, the disassemble command calls the generic
location_completer function, however, the disassemble docs say:

     Note that the 'disassemble' command's address arguments are specified
  using expressions in your programming language (*note Expressions:
  Expressions.), not location specs (*note Location Specifications::).
  So, for example, if you want to disassemble function 'bar' in file
  'foo.c', you must type 'disassemble 'foo.c'::bar' and not 'disassemble
  foo.c:bar'.

And indeed, if I try:

  (gdb) disassemble hello.c:main
  No symbol "hello" in current context.
  (gdb) disassemble hello.c::main
  No symbol "hello" in current context.
  (gdb) disassemble 'hello.c'::main
  Dump of assembler code for function main:
  ... snip ...

But, if I do this:

  (gdb) disassemble hell<TAB>
  (gdb) disassemble hello.c:<CURSOR>

which is a consequence of using the location_completer function.  So
in this commit, after calling skip_over_slash_fmt, I forward the bulk
of the disassemble command completion to expression_completer.  Now
when I try this:

  (gdb) disassemble hell<TAB>

gives nothing, which I think is an improvement.  There is one slight
disappointment, if I do:

  (gdb) disassemble 'hell<TAB>

I still get nothing.  I had hoped that this would expand to:
'hello.c':: but I guess this is a limitation of the current
expression_completer implementation, however, I don't think this is a
regression, the previous expansion was just wrong.  Fixing
expression_completer is out of scope for this commit.

I've added some disassembler command completion tests, and also a test
that disassembling using 'FILE'::FUNC syntax works, as I don't think
that is tested anywhere.

gdb: make skip_over_slash_fmt available outside printcmd.c

Move the function skip_over_slash_fmt into completer.c, and make it
extern, with a declaration in completer.h.

This is a refactor in order to support the next commit.  I've not
changed any of the code in skip_over_slash_fmt.

There should be no user visible changes after this commit.

gdb: error if /r and /b are used with disassemble command

The disassembler gained a new /b flag in this commit:

  commit d4ce49b7ac077a9882d6a5e689e260300045ca88
  Date:   Tue Jun 21 20:23:35 2022 +0100

      gdb: disassembler opcode display formatting

The /b and /r flags result in the instruction opcodes displayed in
different formats, so it's not possible to have both at the same
time.  Currently the /b flag overrides the /r flag.

We have a similar situation with the /m and /s flags, but here, if the
user tries to use both flags then they will get an error.

I think the error is clearer, so in this commit I propose that we add
an error if /r and /b are both used.

Obviously this change breaks backwards compatibility.  I don't have a
compelling argument for why we should make the change beyond my
feeling that it was a mistake not to add this error from the start,
and that the new behaviour is better.

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

gas: S_GET_{NAME,SEGMENT}() don't alter their input symbol

Make their parameters pointer-to-const, thus allowing callers to also be
const-correct where possible.

ld: print branch fixups into the map file for ppc elf targets

In a safety context, it could interesting to track the trampolines being
generated, ensuring there are expected or not.

bfd/ChangeLog:

* elf32-ppc.c (ppc_elf_relax_section): Log branch fixups.

ld/ChangeLog:

* ld.texi (--print-map): Add new item about fixups.

Add minimal thread-safety to BFD

This patch provides some minimal thread-safety to BFD.

The BFD client can request thread-safety by providing a lock and
unlock function.  The globals used during BFD creation (e.g.,
bfd_id_counter) are then locked, and the file descriptor cache is also
locked.  A function to clean up any thread-local data is now provided
for BFD clients.

* bfd-in2.h: Regenerate.
* bfd.c (lock_fn, unlock_fn): New globals.
(bfd_thread_init, bfd_thread_cleanup, bfd_lock, bfd_unlock): New
functions.
* cache.c (bfd_cache_lookup_worker): Use _bfd_open_file_unlocked.
(cache_btell, cache_bseek, cache_bread, cache_bwrite): Lock
and unlock.
(cache_bclose): Add comment.
(cache_bflush, cache_bstat, cache_bmmap): Lock and unlock.
(_bfd_cache_init_unlocked): New function.
(bfd_cache_init): Use it.  Lock and unlock.
(_bfd_cache_close_unlocked): New function.
(bfd_cache_close, bfd_cache_close_all): Use it.  Lock and unlock.
(_bfd_open_file_unlocked): New function.
(bfd_open_file): Use it.  Lock and unlock.
* doc/bfd.texi (BFD front end): Add Threading menu item.
* libbfd.h: Regenerate.
* opncls.c (_bfd_new_bfd): Lock and unlock.
* po/bfd.pot: Regenerate.

Make various error-related globals thread-local

This changes bfd_error et al to be thread-local.

* Makefile.in: Regenerate.
* aclocal.m4: Include ax_tls.m4.
* ax_tls.m4: New file.
* bfd.c: (bfd_error, input_error, input_bfd, _bfd_error_buf):
Now thread-local.
(bfd_asprintf): Update docs.
* config.in, configure: Regenerate.
* configure.ac: Call AX_TLS.
* po/bfd.pot: Regenerate.

Make _bfd_error_buf static

This makes _bfd_error_buf static and adds a way to clear it.  I felt
that this made the subsequent patches a little cleaner.

* bfd.c (_bfd_error_buf): Now static.
(bfd_set_input_error): Use _bfd_clear_error_data.
(_bfd_clear_error_data): New function.
(bfd_init): Use _bfd_clear_error_data.
* libbfd.h: Regenerate.
* opncls.c (bfd_close_all_done): Use _bfd_clear_error_data.
* po/bfd.pot: Regenerate.

Automatic date update in version.in

aarch64: Add LSE128 instructions

Implement, together with the necessary tests, the following new LSE128
atomic instructions:

  * Atomic bit clear on quadword in memory (ldclrp{a|l|al});
  * Atomic bit set on quadword in memory (ldsetp{a|l|al});
  * Swap quadword in memory (swpp{a|l|al});

gas/ChangeLog:

* testsuite/gas/aarch64/lse128-atomic.d: New.
* testsuite/gas/aarch64/lse128-atomic.s: Likewise.

opcodes/ChangeLog:

* aarch64-tbl.h (ldclrp): new _LSE128_INSN entry.
(ldclrpa):  Likewise.
(ldclrpal): Likewise.
(ldclrpl): Likewise.
(ldsetp): Likewise.
(ldsetpa): Likewise.
(ldsetpal): Likewise.
(ldsetpl): Likewise.
(swpp): Likewise.
(swppa): Likewise.
(swppal): Likewise.
(swppl): Likewise.
* aarch64-asm-2.c: Regenerate.
* aarch64-dis-2.c: Likewise.
* aarch64-opc-2.c: Likewise.

aarch64: Add arch support for LSE128 extension

Enable the `+lse128' feature modifier which, together with new
internal feature flags, enables LSE128 instructions, which are
represented via the new `_LSE128_INSN' macro.

gas/ChangeLog:

* config/tc-aarch64.c (aarch64_features): Add new "lse128"
entry.

include/ChangeLog:

* include/opcode/aarch64.h (enum aarch64_feature_bit): New
AARCH64_FEATURE_LSE128 feature bit.
(enum aarch64_insn_class): New lse128_atomic instruction class.

opcodes/ChangeLog:

* opcodes/aarch64-tbl.h (aarch64_feature_lse128): New.
(LSE128): Likewise.
(_LSE128_INSN): Likewise.

aarch64: Add LSE128 instruction operand support

Given the particular encoding of the LSE128 instructions, create the
necessary shared input+output operand register description and
handling in the code to allow for the encoding of the LSE128 128-bit
atomic operations.

gas/ChangeLog:

* config/tc-aarch64.c (parse_operands):

include/ChangeLog:

* opcode/aarch64.h (enum aarch64_opnd):

opcodes/ChangeLog:

* aarch64-opc.c (fields):
(aarch64_print_operand):
* aarch64-opc.h (enum aarch64_field_kind):
* aarch64-tbl.h (AARCH64_OPERANDS):

aarch64: Add 128-bit system register flags

In preparation for the implementation of 128-bit system register
support across the toolchain, this patch adds the feature flag
F_REG_128 and adds it to relevant system registers in
`aarch64-sys-regs.def'.

Given the shared nature of this file, this change is made necessary
initially to implement argument validation in the `__arm_rsr128' and
`__armwsr128' ACLE intrinsics in GCC, but will be of subsequent use in
the binutils implementation of the corresponding `mrrs' and `msrr'
instructions.

Regression tested on aarch64-linux-gnu, no regressions.

opcodes/ChangeLog:

* aarch64-opc.h (F_REG_128):  New flag.
* aarch64-sys-regs.def (par_el1): Add F_REG_128 flag.
(rcwmask_el1): Likewise.
(rcwsmask_el1): Likewise.
(ttbr0_el1): Likewise.
(ttbr0_el12): Likewise.
(ttbr0_el2): Likewise.
(ttbr1_el1): Likewise.
(ttbr1_el12): Likewise.
(ttbr1_el2): Likewise.
(vttbr_el2): Likewise.

aarch64: Add THE system register support

Add Binutils support for system registers associated with the
Translation Hardening Extension (THE).

In doing so, we also add core feature support for THE, enabling its
associated feature flag and implementing the necessary
feature-checking machinery.

Regression tested on aarch64-linux-gnu, no regressions.

gas/ChangeLog:

* config/tc-aarch64.c (aarch64_features): Add "+the" feature modifier.
* doc/c-aarch64.texi (AArch64 Extensions): Update
documentation for `the' option.
* testsuite/gas/aarch64/sysreg-8.s: Add tests for `the'
associated system registers.
* testsuite/gas/aarch64/sysreg-8.d: Likewise.

include/ChangeLog:

* opcode/aarch64.h (enum aarch64_feature_bit): Add
AARCH64_FEATURE_THE.

opcode/ChangeLog:

* aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Add `the'
system register check support.
* aarch64-sys-regs.def: Add `rcwmask_el1' and `rcwsmask_el1'
* aarch64-tbl.h: Define `THE' preprocessor macro.

gdb/arm: remove thumb bit in arm_adjust_breakpoint_address

When compiling gdb with -fsanitize=address on ARM, I get a crash in test
gdb.arch/arm-disp-step.exp, reproduced easily with:

    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end"
    Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step...
    =================================================================
    ==23295==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4a14fd1 at pc 0x01a48871 bp 0xbeab8490 sp 0xbeab8494

Since it doesn't require running the program, it can be reproduced locally on a
dev machine other than ARM, after acquiring the test binary.

The length of the allocate buffer `buf` is 1, and we try to extract an
integer of size 2 from it.  The length of 1 comes from the subtraction
`bpaddr - boundary`.  Normally, on ARM, all instructions are aligned on
a multiple of 2, so it's weird for this subtraction to result in 1.  In
this case, boundary comes from the result of find_pc_partial_function
returning 0x549:

    (gdb) p/x bpaddr
    $2 = 0x54a
    (gdb) p/x boundary
    $3 = 0x549
    (gdb) p/x bpaddr - boundary
    $4 = 0x1

0x549 is the address of the test_call_subr label, 0x548, with the thumb
bit enabled.  Before doing some math with the address, I think we need
to strip the thumb bit, like is done elsewhere (for instance for bpaddr
earlier in the same function).

I wonder if find_pc_partial_function should do that itself, in order to
return an address that is suitable for arithmetic.  In any case, that
would be a change with a broad impact, so for now just fix the issue
locally.

After the patch:

    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end"
    Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step...
    Breakpoint 1 at 0x54a: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/arm-disp-step.S, line 103.

Change-Id: I74fc458dbea0d2c1e1f5eadd90755188df089288
Approved-By: Luis Machado <luis.machado@arm.com>

ld/x86: reduce testsuite dependency on system object files

PR ld/30722
Tests looking for certain .note-section recorded properties may not
involve object files from the underlying platform (e.g. via using the C
compiler for linking): Such object files may themselves have similar
note sections, and hence they may influence the overall outcome.

For now convert just the tests known to be affected by crt*.o coming
with "ISA v3 needed" notes. Eventually other tests ought to be
converted, too.

Revert "ld x86_64 tests: Accept x86-64-v3 as a needed ISA"

This reverts commit bf77f42f6708d8b5ba92336d876042826d8d29c1.
It wrongly altered testcase expectations; the issue will need
taking care of differently.

RISC-V: Add support for XCValu extension in CV32E40P

Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html

Contributors:
  Mary Bennett <mary.bennett@embecosm.com>
  Nandni Jamnadas <nandni.jamnadas@embecosm.com>
  Pietra Ferreira <pietra.ferreira@embecosm.com>
  Charlie Keaney
  Jessica Mills
  Craig Blackmore <craig.blackmore@embecosm.com>
  Simon Cook <simon.cook@embecosm.com>
  Jeremy Bennett <jeremy.bennett@embecosm.com>
  Helene Chelin <helene.chelin@embecosm.com>

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvalu`
          instruction class.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* config/tc-riscv.c (validate_riscv_insn): Added the necessary
          operands for the extension.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Noted XCValu as an additional ISA extension
          for CORE-V.
* testsuite/gas/riscv/cv-alu-boundaries.d: New test.
* testsuite/gas/riscv/cv-alu-boundaries.l: New test.
* testsuite/gas/riscv/cv-alu-boundaries.s: New test.
* testsuite/gas/riscv/cv-alu-fail-march.d: New test.
* testsuite/gas/riscv/cv-alu-fail-march.l: New test.
* testsuite/gas/riscv/cv-alu-fail-march.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-01.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-01.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-01.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-02.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-02.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-02.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-03.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-03.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-03.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-04.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-04.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-04.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-05.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-05.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-05.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-06.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-06.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-06.s: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-07.d: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-07.l: New test.
* testsuite/gas/riscv/cv-alu-fail-operand-07.s: New test.
* testsuite/gas/riscv/cv-alu-insns.d: New test.
* testsuite/gas/riscv/cv-alu-insns.s: New test.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Disassemble xcb operand.
* riscv-opc.c: Defined the MASK and added XCValu instructions.

include/ChangeLog:

* opcode/riscv-opc.h: Added corresponding MATCH and MASK macros
          for XCValu.
* opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros
          for XCValu.
(enum riscv_insn_class): Added the XCValu instruction class.

RISC-V: Add support for XCVmac extension in CV32E40P

Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html

Contributors:
  Mary Bennett <mary.bennett@embecosm.com>
  Nandni Jamnadas <nandni.jamnadas@embecosm.com>
  Pietra Ferreira <pietra.ferreira@embecosm.com>
  Charlie Keaney
  Jessica Mills
  Craig Blackmore <craig.blackmore@embecosm.com>
  Simon Cook <simon.cook@embecosm.com>
  Jeremy Bennett <jeremy.bennett@embecosm.com>
  Helene Chelin <helene.chelin@embecosm.com>

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvmac`
          instruction class.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* config/tc-riscv.c (validate_riscv_insn): Added the necessary
          operands for the extension.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Noted XCVmac as an additional ISA extension
          for CORE-V.
* testsuite/gas/riscv/cv-mac-fail-march.d: New test.
* testsuite/gas/riscv/cv-mac-fail-march.l: New test.
* testsuite/gas/riscv/cv-mac-fail-march.s: New test.
* testsuite/gas/riscv/cv-mac-fail-operand.d: New test.
* testsuite/gas/riscv/cv-mac-fail-operand.l: New test.
* testsuite/gas/riscv/cv-mac-fail-operand.s: New test.
* testsuite/gas/riscv/cv-mac-insns.d: New test.
* testsuite/gas/riscv/cv-mac-insns.s: New test.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Disassemble information with
          the EXTRACT macro implemented.
* riscv-opc.c: Defined the MASK and added
          XCVmac instructions.

include/ChangeLog:

* opcode/riscv-opc.h: Added corresponding MATCH and MASK macros
          for XCVmac.
* opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros
          for uimm.
(enum riscv_insn_class): Added the XCVmac instruction class.

Remove EXTERN_C and related defines

common-defs.h has a few defines that I suspect were used during the
transition to C++.  These aren't needed any more, so remove them.

Tested by rebuilding.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>

Automatic date update in version.in

gdb: Update email address for Carl Love in gdb/MAINTAINERS

Fix resizing of TUI python windows

When resizing from a big to small terminal size, and you have a
TUI python window that would then be outside of the new size,
valgrind shows this error:

==3389== Invalid read of size 1
==3389==    at 0xC3DFEE: wnoutrefresh (lib_refresh.c:167)
==3389==    by 0xC3E3C9: wrefresh (lib_refresh.c:63)
==3389==    by 0xA9766C: tui_unhighlight_win(tui_win_info*) (tui-wingeneral.c:134)
==3389==    by 0x98921C: tui_py_window::rerender() (py-tui.c:183)
==3389==    by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030)
==3389==    by 0xA8C2A2: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1033)
==3389==    by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030)
==3389==    by 0xA8B1F8: tui_apply_current_layout(bool) (tui-layout.c:81)
==3389==    by 0xA95CDB: tui_resize_all() (tui-win.c:525)
==3389==    by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562)
==3389==    by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234)
==3389==    by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199)
==3389==  Address 0x115cc214 is 1,332 bytes inside a block of size 2,240 free'd
==3389==    at 0x4A0A430: free (vg_replace_malloc.c:446)
==3389==    by 0xC3CF7D: _nc_freewin (lib_newwin.c:121)
==3389==    by 0xA8B1C6: tui_apply_current_layout(bool) (tui-layout.c:78)
==3389==    by 0xA95CDB: tui_resize_all() (tui-win.c:525)
==3389==    by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562)
==3389==    by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234)
==3389==    by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199)
==3389==    by 0x8E40E9: captured_command_loop() (main.c:407)
==3389==    by 0x8E5E54: gdb_main(captured_main_args*) (main.c:1324)
==3389==    by 0x62AC04: main (gdb.c:39)

It's because tui_py_window::m_inner_window still has the outside
coordinates, and wnoutrefresh then does an out-of-bounds access.

Fix this by resetting m_inner_window on every resize, it will anyways
be recreated in the next rerender call.

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

Change gdb.base/examine-backwards.exp for AIX.

In AIX unused or constant variables are collected as garbage by the linker and in the dwarf dump
an address with all f's in hexadecimal are assigned. Hence the testcase fails with many failures stating
it cannot access memory.

This patch is a small change to get it working in AIX as well.

ld: =fillexp different behaviors for hexidecimal literal

  PR 30865
  * ld.texi: Update description of the FILL command.
  * testsuite/ld-scripts/fill2.d: New test.
  * testsuite/ld-scripts/fill2.t: New test source.
  * testsuite/ld-scripts/data.exp: Run the new test.

RISC-V: Make sure rv32q conflict won't affect the fp-q-insns-32 gas testcase.

Same as commit 4352c0ac04a.

gas/
* testsuite/gas/riscv/fp-q-insns-32.d: Set q to v2.2.

RISC-V: Moved out linker internal relocations after R_RISCV_max.

Just the lightest modifications about this, without any further checks and
considering --emit-relocs.  We will need to improve it in the future, but
first do this to avoid conflicts between linker internal relocations and the
new definition of psabi.  For example, TLSDESC relocs.

Passed riscv-gnu-toolchain regressions, so should be safe enough to commit.

Co-authored-by: Tsukasa OI <research_trasio@irq.a4lg.com>
bfd/
* reloc.c: Removed linker internal relocations.
* bfd-in2.h: Regenerated.
* libbfd.h: Regenerated.
* elfnn-riscv.c: Defined R_RISCV_DELETE in include/elf/riscv.h.
* elfxx-riscv.c (howto_table, howto_table_internal): Moved linker
internal relocations from howto_table into howto_table_internal.
(riscv_reloc_map): Removed linker internal relocations mapping.
(riscv_elf_rtype_to_howto): Return howto of linker internal
relocations from howto_table_internal.
include/
* elf/riscv.h: Defined linker internal relocations after R_RISCV_max.

[gdb/testsuite] Fix gdb.dwarf2/dw2-gas-workaround.exp

Recently added test-case gdb.dwarf2/dw2-gas-workaround.exp:
- passes when gdb is configured using $(cd ../src; pwd)/configure, but
- fails when using ../src/configure.

Fix this by making the matching more precise:
...
-    -re -wrap "$objdir.*" {
+    -re -wrap "name_for_id = $objdir/$srcfile\r\n.*" {
...
such that we only fail on the line:
...
[symtab-create] start_subfile: name = dw2-lines.c, name_for_id = \
  /data/vries/gdb/leap-15-4/build/gdb/testsuite/dw2-lines.c^M
...

Reported-By: Carl Love <cel@us.ibm.com>

Automatic date update in version.in

Pre-read DWZ file in DWARF reader

While working on background reading of DWARF, I came across the
DWZ-reading code.  This code can query the user (via the debuginfod
support) -- something that cannot be done off the main thread.

Looking into it, I realized that this code can be run much earlier,
avoiding this problem.  Digging a bit deeper, I also found a
discrepancy here between how the DWARF reader works in "readnow" mode
as compared to the normal modes.

This patch cleans this up by trying to read the DWZ file earlier, and
also by having the DWARF reader convert any exception here into a
warning.  This unifies the various cases, but also makes it so that
errors do not prevent gdb from continuing on to the extent possible.

Regression tested on x86-64 Fedora 38.

Automatic date update in version.in

Automatic date update in version.in

Remove unused declaration

I found a declaration in py-stopevent.h for which there is no
definition.  This patch removes it.

gdbsupport: mark array_view::slice with [[nodiscard]]

I (almost) had a bug where I did:

    buffer.slice (...)

but I meant:

    buffer = buffer.slice (...)

The first one does nothing, it creates a new array_view but without
using it, it's useless.  Mark the slice methods with [[nodiscard]]
(which is standard C++17) so that error would generate a warning.

I guess that many functions could be marked as nodiscard, essentially
function that is pure (doesn't have side-effects).  But this one seems
particularly easy to mis-use.

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

gdbsupport: record and print failed selftest names

Since "maint selftest" now runs quite a lot of tests (especially in an
all-targets build), I thought it would be useful to print a summary at
the end of what failed.  So, implement that.

Print the summary before the "Ran %d unit tests, %zu failed\n" line, so
that that one remains the last line, and the gdb.gdb/unittest.exp
doesn't need to be changed.

The output looks like (if I force a failure in a test):

    (gdb) maint selftest
    ...
    Running selftest value_copy.
    Running selftest xml_escape_text.
    Running selftest xml_escape_text_append.

    Failures:
      aarch64-analyze-prologue

    Ran 4134 unit tests, 1 failed
    (gdb)

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

gas: correct ignoring of C-style number suffixes

First of all the respective original changes didn't deal with just 0
having such a suffix - this needs additional logic outside of
integer_constant(). Further bogus suffixes having more than two L-s
were accepted, while valid suffixes with U following the L(s) weren't.
Finally respective tests were introduced for Sparc only.

Reviewed-by: Neal Frager <neal.frager@amd.com>

RISC-V: reduce redundancy in load/store macro insn handling

Within the groups L{B,BU,H,HU,W,WU,D}, S{B,H,W,D}, FL{H,W,D,Q}, and
FS{H,W,D,Q} the sole difference between the handling is the insn
mnemonic passed to the common handling functions. The intended mnemonic,
however, can easily be retrieved. Furthermore leverags that Sx and FSx
are then handled identically, too, and hence their cases can also be
folded.

RISC-V: Lx/Sx macro insn tests

Make sure these (continue to) work as intended.

RISC-V: add F- and D-extension testcases

Make sure future changes won't regress any of this. Also cover the FLH
and FSH macro insns of the Zfh extension.

RISC-V: make FLQ/FSQ macro-insns work

When support for the Q extension was added, the libopcodes side of these
macro-insns was properly covered, but no backing support in gas was
added. In new testcases cover not just these, but all Q-extension insns.

Automatic date update in version.in

[gdb/tdep] Fix nr array elements in ppc64_aggregate_candidate

On AlmaLinux 9.2 powerpc64le I run into:
...
(gdb) PASS: gdb.ada/array_return.exp: continuing to Create_Small_Float_Vector
finish^M
Run till exit from #0  pck.create_small_float_vector () at pck.adb:30^M
0x00000000100022d4 in p () at p.adb:25^M
25         Vector := Create_Small_Float_Vector;^M
Value returned is $3 = (2.80259693e-45, 2.80259693e-45)^M
(gdb) FAIL: gdb.ada/array_return.exp: value printed by finish of Create_Small_Float_Vector
...
while this is expected:
...
Value returned is $3 = (4.25, 4.25)^M
...

The problem is here in ppc64_aggregate_candidate:
...
  if (!get_array_bounds (type, &low_bound, &high_bound))
    return -1;
  count *= high_bound - low_bound
...

The array type (containing 2 elements) is:
...
   type Small_Float_Vector is array (1 .. 2) of Float;
...
so we have:
...
(gdb) p low_bound
$1 = 1
(gdb) p high_bound
$2 = 2
...
but we calculate the number of elements in the array using
"high_bound - low_bound", which is 1.

Consequently, gdb fails to correctly classify the type as a ELFv2 homogeneous
aggregate.

Fix this by calculating the number of elements in the array by using
"high_bound - low_bound + 1" instead.

Furthermore, high_bound can (in general, though perhaps not here) also be
smaller than low_bound, so to be safe take that into account as well:
...
  LONGEST nr_array_elements = (low_bound > high_bound
       ? 0
       : (high_bound - low_bound + 1));
  count *= nr_array_elements;
...

Tested on powerpc64le-linux.

Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
PR tdep/31015
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31015

aarch64: Add GCS system registers.

This patch adds support for 10 new AArch64 system registers
(gcscre0_el1, gcscr_el1, gcscr_el12, gcscr_el2, gcscr_el3,
gcspr_el0, gcspr_el1 ,gcspr_el12, gcspr_el2 and gcspr_el3),
which are enabled on using Guarded Control Stack (+gcs flag)
feature.

aarch64: Add support for GCSB DSYNC instruction.

This patch adds support for Guarded control stack data synchronization
instruction (GCSB DSYNC). This instruction is allocated to existing
HINT space and uses the HINT number 19 and to match this an entry is
added to the aarch64_hint_options array.

aarch64: Add support for GCS extension.

This patch adds for Guarded Control Stack Extension (GCS) extension. GCS feature is
optional from Armv9.4-A architecture and enabled by passing +gcs option to -march
(eg: -march=armv9.4-a+gcs) or using ".arch_extension gcs" directive in the assembly file.

Also this patch adds support for GCS instructions gcspushx, gcspopcx, gcspopx,
gcsss1, gcsss2, gcspushm, gcspopm, gcsstr and gcssttr.

aarch64: Add support for Check Feature Status Extension.

This patch adds support for Check Feature Status Extension (CHK) which
is mandatory from Armv8.0-A. Also this patch supports "chkfeat" instruction
(hint #40).

aarch64: Add support for Armv8.9-A and Armv9.4-A Architectures.

This patch adds AArch64 support for Armv8.9-A architecture (-march=armv8.9-a)
and Armv9.4-A architecture (-march=armv9.4-a).

ld x86_64 tests: Accept x86-64-v3 as a needed ISA

  * testsuite/ld-x86-64/property-3.r: Update regexp to allow for targets which support x86-64-v3.
  * testsuite/ld-x86-64/property-4.r: Likewise.
  * testsuite/ld-x86-64/property-5.r: Likewise.

gprofng: remove dependency on help2man

help2man is no longer used to create the gprofng man pages.

gprofng/ChangeLog
2023-10-31  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* configure.ac: Remove HELP2MAN.
* Makefile.in: Rebuild.
* configure: Rebuild.
* doc/Makefile.in: Rebuild.
* gp-display-html/Makefile.in: Rebuild.
* src/Makefile.in: Rebuild.

Automatic date update in version.in

gdb: use gdb::byte_vector instead of gdb::def_vector<gdb_byte>

Use the gdb::byte_vector typedef when possible.

Change-Id: Ib2199201c052496992011ea02979de023d4d8a9a

Fix typo in recent update to the ld/NEWS file

ld: Support input section description keyword: REVERSE

  PR 27565
  * ldlex.l: Add REVERSE.
  * ldgram.y: Allow REVERSE to be used wherever a sorting command can be used.
  * ld.h (struct wildcard_spec): Add 'reversed' field.
  * ldlang.h (lang_wild_statement_struct): Add 'filenames_reversed' field.
  * ldlang.c (compare_sections): Add reversed parameter. (wild_sort): Reverse the comparison if requested. (print_wild_statement): Handle the reversed field.
  * ld.texi: Document the new feature.
  * NEWS: Mention the new feature.
  * testsuite/ld-scripts/sort-file-reversed-1.d: New test driver.
  * testsuite/ld-scripts/sort-file-reversed-1.t: New test source.
  * testsuite/ld-scripts/sort-file-reversed-2.t: New test source.
  * testsuite/ld-scripts/sort-file-reversed-2.d: New test driver.
  * testsuite/ld-scripts/sort-sections-reversed-1.d: New test driver.
  * testsuite/ld-scripts/sort-sections-reversed-1.t: New test source.
  * testsuite/ld-scripts/sort-sections-reversed-2.t: New test source.
  * testsuite/ld-scripts/sort-sections-reversed-2.d: New test driver.
  * testsuite/ld-scripts/sort-sections-reversed-3.d: New test driver.
  * testsuite/ld-scripts/sort-sections-reversed-3.t: New test source.

Automatic date update in version.in

[gdb/symtab] Work around gas PR28629

When running test-case gdb.tui/tui-layout-asm-short-prog.exp on AlmaLinux 9.2
ppc64le, I run into:
...
FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents
...

The problem is that we get:
...
    7              [ No Assembly Available ]
...
because tui_get_begin_asm_address doesn't succeed.

In more detail, tui_get_begin_asm_address calls:
...
    find_line_pc (sal.symtab, sal.line, &addr);
...
with:
...
(gdb) p *sal.symtab
$5 = {next = 0x130393c0, m_compunit = 0x130392f0, m_linetable = 0x0,
  filename = "tui-layout-asm-short-prog.S",
  filename_for_id = "$gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S",
  m_language = language_asm, fullname = 0x0}
(gdb) p sal.line
$6 = 1
...

The problem is the filename_for_id which is the source file prefixed with the
compilation dir rather than the source dir.

This is due to faulty debug info generated by gas, PR28629:
...
    <1a>   DW_AT_name        : tui-layout-asm-short-prog.S
    <1e>   DW_AT_comp_dir    : $gdb/build/gdb/testsuite
    <22>   DW_AT_producer    : GNU AS 2.35.2
...

The DW_AT_name is relative, and it's relative to the DW_AT_comp_dir entry,
making the effective name $gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S.

The bug is fixed starting version 2.38, where we get instead:
...
    <1a>   DW_AT_name        :
             $gdb/src/gdb/testsuite/gdb.tui/tui-layout-asm-short-prog.S
    <1e>   DW_AT_comp_dir    : $gdb/build/gdb/testsuite
    <22>   DW_AT_producer    : GNU AS 2.38
...

Work around the faulty debug info by constructing the filename_for_id using
the second directory from the directory table in the .debug_line header:
...
 The Directory Table (offset 0x22, lines 2, columns 1):
  Entry Name
  0 $gdb/build/gdb/testsuite
  1 $gdb/src/gdb/testsuite/gdb.tui
...

Note that the used gas contains a backport of commit 3417bfca676 ("GAS:
DWARF-5: Ensure that the 0'th entry in the directory table contains the
current working directory."), because directory 0 is correct.  With the
unpatched 2.35.2 release the directory 0 entry is incorrect: it's a copy of
entry 1.

Add a dwarf assembly test-case that reflects the debug info as generated by
unpatched gas 2.35.2.

Tested on x86_64-linux.

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

[gdb/symtab] Add producer_is_gas

Add producer_is_gas, a generic way to get the gas version from the
producer string.

Tested on x86_64-linux.

Implement DAP setVariable request

This patch implements the DAP setVariable request.

setVariable is a bit odd in that it specifies the variable to modify
by passing in the variable's container and the name of the variable.
This approach can't handle variable shadowing (there are a couple of
open DAP bugs on this topic), so this patch renames duplicates to
avoid the problem.

Support Intel USER_MSR

This patches aims to support Intel USER_MSR. In addition to the usual
support, this patch includes encoding and decoding support for MAP7 and
immediate numbers as the last operand (ATT style).

gas/ChangeLog:

* NEWS: Support Intel USER_MSR.
* config/tc-i386.c (smallest_imm_type): Reject imm32 in 64bit
mode.
(build_vex_prefix): Add VEXMAP7.
(md_assemble): Handling the imm32 of USER_MSR.
(match_template): Handling the unusual immediate.
* doc/c-i386.texi: Document .user_msr.
* testsuite/gas/i386/i386.exp: Run USER_MSR tests.
* testsuite/gas/i386/x86-64.exp: Ditto.
* testsuite/gas/i386/user_msr-inval.l: New test.
* testsuite/gas/i386/user_msr-inval.s: Ditto.
* testsuite/gas/i386/x86-64-user_msr-intel.d: Ditto.
* testsuite/gas/i386/x86-64-user_msr-inval.l: Ditto.
* testsuite/gas/i386/x86-64-user_msr-inval.s: Ditto.
* testsuite/gas/i386/x86-64-user_msr.d: Ditto.
* testsuite/gas/i386/x86-64-user_msr.s: Ditto.

opcodes/ChangeLog:
* i386-dis.c (struct instr_info): Add a new attribute
has_skipped_modrm.
(Gq): New.
(Rq): Ditto.
(q_mm_mode): Ditto.
(Nq): Change mode from q_mode to q_mm_mode.
(VEX_LEN_TABLE):
(get_valid_dis386): Add VEX_MAP7 in VEX prefix.
and handle the map7_f8 for save space.
(OP_Skip_MODRM): Set has_skipped_modrm.
(OP_E): Skip codep++ when has skipped modrm byte.
(OP_R): Support q_mode and q_mm_mode.
(REG_VEX_MAP7_F8_L_0_W_0): New.
(PREFIX_VEX_MAP7_F8_L_0_W_0_R_0_X86_64): Ditto.
(X86_64_VEX_MAP7_F8_L_0_W_0_R_0): Ditto.
(VEX_LEN_MAP7_F8): Ditto.
(VEX_W_MAP7_F8_L_0): Ditto.
(MOD_0F38F8): Ditto.
(PREFIX_0F38F8_M_0): Ditto.
(PREFIX_0F38F8_M_1_X86_64): Ditto.
(X86_64_0F38F8_M_1): Ditto.
(PREFIX_0F38F8): Remove.
(prefix_table): Add PREFIX_0F38F8_M_1_X86_64.
Remove PREFIX_0F38F8.
(reg_table): Add REG_VEX_MAP7_F8_L_0_W_0,
PREFIX_VEX_MAP7_F8_L_0_W_0_R_0_X86_64.
(x86_64_table): Add X86_64_0F38F8_PREFIX_3_M_1,
X86_64_VEX_MAP7_F8_L_0_W_0_R_0 and X86_64_0F38F8_M_1.
(vex_table): Add VEX_MAP7.
(vex_len_table): Add VEX_LEN_MAP7_F8,
VEX_W_MAP7_F8_L_0.
(mod_table): New entry for USER_MSR and
add MOD_0F38F8.
* i386-gen.c (cpu_flag_init): Add CPU_USER_MSR_FLAGS and
CPU_ANY_USER_MSR_FLAGS. Add add VEXMAP7.
* i386-init.h: Regenerated.
* i386-mnem.h: Ditto.
* i386-opc.h (SPACE_VEXMAP7): New.
(CPU_USER_MSR_FLAGS): Ditoo.
(CPU_ANY_USER_MSR_FLAGS): Ditto.
(i386_cpu_flags): Add cpuuser_msr.
* i386-opc.tbl: Add USER_MSR instructions.
* i386-tbl.h: Regenerated.

Remove some frame invalidation code

I stumbled across a few spots that mention that a function
"invalidates frame" and also assignments of NULL to a frame_info_ptr.
This code isn't harmful, but is also unnecessary since the
introduction of frame_info_ptr -- nowadays frame invalidations are
handled automatically.

Regression tested on x86-64 Fedora 38.

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

Automatic date update in version.in

New Georgian translation for the ld sub-directory

gas: bpf: new test for MOV with C-like numbers ll suffix

The BPF pseudo-c syntax supports both MOV and LDDW instructions:

    mov:  r1 = EXPR
    lddw: r1 = EXPR ll

Note that the white space between EXPR and `ll' is necessary in order
to avoid ambiguity with the assembler's support for C-like numerical
suffixes.  This patch adds a new test to the GAS BPF testsuite to make
sure that instructions like:

    r1 = 666ll

are interpreted as `mov %r1,666', not as `lddw %r1,666'.

This matches clang's assembler behavior.

2023-10-30  Jose E. Marchesi  <jose.marchesi@oracle.com>

* testsuite/gas/bpf/alu-pseudoc.s: Add test to make sure C-like
suffix `ll' is not interpreted as lddw syntax.
* testsuite/gas/bpf/alu-pseudoc.d: Update expected results.
* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.

Fix fixed-point "return" on ARM

On a big-endian ARM machine, the "return" command resulted in the
wrong value being returned when the function had a fixed-point return
type.  This patch fixes the problem by unpacking and repacking the
fixed-point type appropriately.

Approved-By: Luis Machado <luis.machado@arm.com>

Fix range-type "return" command on ARM

On big-endian ARM, "return"ing from a function that returned a range
type did not work.  This patch strips the range type to treat the
function as though it were returning the underlying type instead.

Approved-By: Luis Machado <luis.machado@arm.com>

Fix "finish" for vector types on ARM

On a big-endian ARM system, "finish" printed the wrong value when
finishing from a function that returned a vector type.  Similarly,
calls to a function also resulted in the wrong value being passed.  I
think both the read- and write-functions here should ignore the
endian-ness.

I tested this using the AdaCore internal test suite; the test case
that caught this is identical to gdb.base/gnu_vector.exp.

Approved-By: Luis Machado <luis.machado@arm.com>

Fix "finish" with range types on ARM

On ARM (I tested big-endian but it may not matter), "finish" can
sometimes print the wrong result when the return type is a range type.
Range types should really be treated as their underlying type
(normally integer, but sometimes fixed-point).  This patch implements
this.

Approved-By: Luis Machado <luis.machado@arm.com>

Fix calls with small integers on ARM

On big-endian ARM, an inferior call with a small integer will pass the
wrong value.  This patch fixes the problem.  Because the code here
works using scalar values, and not just bytes, left-shifting is
unnecessary.

Approved-By: Luis Machado <luis.machado@arm.com>

Accept and ignore the R_BPF_64_NODLYD32 relocation.

aarch64: Update aarch64-sys-regs.def header

Given the shared use of the aarch64-sys-regs.def file across Binutils
and GCC, add instructions for keeping the file synchronized across the
two codebases.

Namely, it should be made clear that all changes are first to be made
in Binutils and the updated file copied across to GCC.

opcodes/ChangeLog

* opcodes/aarch64-sys-regs.def: Update file-description header
comment.

Automatic date update in version.in

Move read_addrmap_from_aranges to new file

In the interest of shrinking dwarf2/read.c a little more, this patch
moves the code that deciphers .debug_aranges into a new file.

Reviewed-By: Guinevere Larsen <blarsen@redhat.com>

Pre-read .debug_aranges section

While working on background DWARF reading, I found a race case that I
tracked down to the handling of the .debug_aranges section.  Currently
the section data is only read in after the CUs have all been created.
However, there's no real reason to do this -- it seems fine to read it
a little earlier, when all the other necessary sections are read in.

This patch makes this change, and updates the
read_addrmap_from_aranges API to assert that the section is read in.

This patch slightly changes the read_addrmap_from_aranges API as well,
to reject an empty section.  This seems better to me than what the
current code does, which is try to read an empty section but then do
no work.

Regression tested on x86-64 Fedora 38.

Reviewed-By: Guinevere Larsen <blarsen@redhat.com>

Automatic date update in version.in

gdb/gdbsupport/gdbserver: Require c++17

This patch proposes to require a C++17 compiler to build gdb /
gdbsupport / gdbserver.  Before this patch, GDB required a C++11
compiler.

The general policy regarding bumping C++ language requirement in GDB (as
stated in [1]) is:

    Our general policy is to wait until the oldest compiler that
    supports C++NN is at least 3 years old.

    Rationale: We want to ensure reasonably widespread compiler
    availability, to lower barrier of entry to GDB contributions, and to
    make it easy for users to easily build new GDB on currently
    supported stable distributions themselves. 3 years should be
    sufficient for latest stable releases of distributions to include a
    compiler for the standard, and/or for new compilers to appear as
    easily installable optional packages. Requiring everyone to build a
    compiler first before building GDB, which would happen if we
    required a too-new compiler, would cause too much inconvenience.

    See the policy proposal and discussion
    [here](https://sourceware.org/ml/gdb-patches/2016-10/msg00616.html).

The first GCC release which with full C++17 support is GCC-9[2],
released in 2019[3], which is over 4 years ago.  Clang has had C++17
support since Clang-5[4] released in 2018[5].

A discussions with many distros showed that a C++17-able compiler is
always available, meaning that this no hard requirement preventing us to
require it going forward.

[1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F
[2] https://gcc.gnu.org/projects/cxx-status.html#cxx17
[3] https://gcc.gnu.org/gcc-9/
[4] https://clang.llvm.org/cxx_status.html
[5] https://releases.llvm.org/

Change-Id: Id596f5db17ea346e8a978668825787b3a9a443fd
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>

gdb/ax_cxx_compile_stdcxx.m4: upgrade

This patch upgrades gdb/ax_cxx_compile_stdcxx.m4 to follow changes
available in [1] and regenerates the configure script.

[1] https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html

Change-Id: I5b16adc65c9e48a13ad65202d58ab7a9d487214e
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>

gas: tc-bpf.c: fix formatting of comment

opcodes: bpf-dis.c: fix typo in comment

Automatic date update in version.in

gdb: trim trailing spaces in i386-tdep.{c,h}

Change-Id: I06c2e7c958c3451f00c70978538c1c2ad1b566df

RISC-V: Clarify the behaviors of SET/ADD/SUB relocations.

We are used to generate these kinds of relocations by data directives.
Considering the following example,
.word (A + 3) - (B + 2)
The GAS will generate a pair of ADD/SUB for this,
R_RISCV_ADD, A + 1
R_RISCV_SUB, 0

The addend of R_RISCV_SUB will always be zero, and the summary of the
constants will be stored in the addend of R_RISCV_ADD/SET.  Therefore,
we can always add the addend of these data relocations when doing relocations.

But unfortunately, I had heard that if we are using .reloc to generate
the data relocations will make the relocations failed.  Refer to this,
.reloc offset, R_RISCV_ADD32, A + 3
.reloc offset, R_RISCV_SUB32, B + 2
.word 0
Then we can get the relocations as follows,
R_RISCV_ADD, A + 3
R_RISCV_SUB, B + 2
Then...  Current LD does the relocation, B - A + 3 + 2, which is wrong
obviously...

So first of all, this patch fixes the wrong relocation behavior of
R_RISCV_SUB* relocations.

Afterwards, considering the uleb128 direcitve, we will get a pair of
SET_ULEB128/SUB_ULEB128 relocations for it for now,
.uleb128 (A + 3) - (B + 2)
R_RISCV_SET_ULEB128, A + 1
R_RISCV_SUB_ULEB128, B + 1

Which looks also wrong obviously, the summary of the constants should only
be stored into the addend of SET_ULEB128, and the addend of SUB_ULEB128 should
be zero like other SUB relocations.  But the current LD will still get the right
relocation values since we only add the addend of SUB_ULEB128 by accident...
Anyway, this patch also fixes the behaviors above, to make sure that no matter
using .uleb128 or .reloc directives, we should always get the right values.

bfd/
* elfnn-riscv.c (perform_relocation):  Clarify that SUB relocations
should substract the addend, rather than add.
(riscv_elf_relocate_section): Since SET_ULEB128 won't go into
perform_relocation, we should add it's addend here in advance.
gas/
* config/tc-riscv.c (riscv_insert_uleb128_fixes): Set the addend of
SUB_ULEB128 to zero since it should already be added into the addend
of SET_ULEB128.

Automatic date update in version.in

gdb/python: Add new gdb.Value.bytes attribute

Add a gdb.Value.bytes attribute.  This attribute contains the bytes of
the value (assuming the complete bytes of the value are available).

If the bytes of the gdb.Value are not available then accessing this
attribute raises an exception.

The bytes object returned from gdb.Value.bytes is cached within GDB so
that the same bytes object is returned each time.  The bytes object is
created on-demand though to reduce unnecessary work.

For some values we can of course obtain the same information by
reading inferior memory based on gdb.Value.address and
gdb.Value.type.sizeof, however, not every value is in memory, so we
don't always have an address.

The gdb.Value.bytes attribute will convert any value to a bytes
object, so long as the contents are available.  The value can be one
created purely in Python code, the value could be in a register,
or (of course) the value could be in memory.

The Value.bytes attribute can also be assigned too.  Assigning to this
attribute is similar to calling Value.assign, the value of the
underlying value is updated within the inferior.  The value assigned
to Value.bytes must be a buffer which contains exactly the correct
number of bytes (i.e. unlike value creation, we don't allow oversized
buffers).

To support this assignment like behaviour I've factored out the core
of valpy_assign.  I've also updated convert_buffer_and_type_to_value
so that it can (for my use case) check the exact buffer length.

The restrictions for when the Value.bytes can or cannot be written too
are exactly the same as for Value.assign.

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

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb: handle main thread exiting during detach

Overview
========

Consider the following situation, GDB is in non-stop mode, the main
thread is running while a second thread is stopped.  The user has the
second thread selected as the current thread and asks GDB to detach.
At the exact moment of detach the main thread exits.

This situation currently causes crashes, assertion failures, and
unexpected errors to be reported from GDB for both native and remote
targets.

This commit addresses this situation for native and remote targets.
There are a number of different fixes, but all are required in order
to get this functionality working correct for native and remote
targets.

Native Linux Target
===================

For the native Linux target, detaching is handled in the function
linux_nat_target::detach.  In here we call stop_wait_callback for each
thread, and it is this callback that will spot that the main thread
has exited.

GDB then detaches from everything except the main thread by calling
detach_callback.

After this the first problem is this assert:

  /* Only the initial process should be left right now.  */
  gdb_assert (num_lwps (pid) == 1);

The num_lwps call will return 0 as the main thread has exited and all
of the other threads have now been detached.  I fix this by changing
the assert to allow for 0 or 1 lwps at this point.  As the 0 case can
only happen in non-stop mode, the assert becomes:

  gdb_assert (num_lwps (pid) == 1
      || (target_is_non_stop_p () && num_lwps (pid) == 0));

The next problem is that we do:

  main_lwp = find_lwp_pid (ptid_t (pid));

and then proceed assuming that main_lwp is not nullptr.  In the case
that the main thread has exited though, main_lwp will be nullptr.

However, we only need main_lwp so that GDB can detach from the
thread.  If the main thread has exited, and GDB has already detached
from every other thread, then GDB has finished detaching, GDB can skip
the calls that try to detach from the main thread, and then tell the
user that the detach was a success.

For Remote Targets
==================

On remote targets there are two problems.

First is that when the exit occurs during the early phase of the
detach, we see the stop notification arrive while GDB is removing the
breakpoints ahead of the detach.  The 'set debug remote on' trace
looks like this:

  [remote] Sending packet: $z0,7f1648fe0241,1#35
  [remote]   Notification received: Stop:W0;process:2a0ac8
  # At this point an unpatched gdbserver segfaults, and the connection
  # is broken.  A patched gdbserver continues as below...
  [remote] Packet received: E01
  [remote] Sending packet: $z0,7f1648ff00a8,1#68
  [remote] Packet received: E01
  [remote] Sending packet: $z0,7f1648ff132f,1#6b
  [remote] Packet received: E01
  [remote] Sending packet: $D;2a0ac8#3e
  [remote] Packet received: E01

I was originally running into Segmentation Faults, from within
gdbserver/mem-break.cc, in the function find_gdb_breakpoint.  This
function calls current_process() and then dereferences the result to
find the breakpoint list.

However, in our case, the current process has already exited, and so
the current_process() call returns nullptr.  At the point of failure,
the gdbserver backtrace looks like this:

  #0  0x00000000004190e4 in find_gdb_breakpoint (z_type=48 '0', addr=4198762, kind=1) at ../../src/gdbserver/mem-break.cc:982
  #1  0x000000000041930d in delete_gdb_breakpoint (z_type=48 '0', addr=4198762, kind=1) at ../../src/gdbserver/mem-break.cc:1093
  #2  0x000000000042d8db in process_serial_event () at ../../src/gdbserver/server.cc:4372
  #3  0x000000000042dcab in handle_serial_event (err=0, client_data=0x0) at ../../src/gdbserver/server.cc:4498
  ...

The problem is that, as a result non-stop being on, the process
exiting is only reported back to GDB after the request to remove a
breakpoint has been sent.  Clearly gdbserver can't actually remove
this breakpoint -- the process has already exited -- so I think the
best solution is for gdbserver just to report an error, which is what
I've done.

The second problem I ran into was on the gdb side, as the process has
already exited, but GDB has not yet acknowledged the exit event, the
detach -- the 'D' packet in the above trace -- fails.  This was being
reported to the user with a 'Can't detach process' error.  As the test
actually calls detach from Python code, this error was then becoming a
Python exception.

Though clearly the detach has returned an error, and so, maybe, having
GDB throw an error would be fine, I think in this case, there's a good
argument that the remote error can be ignored -- if GDB tries to
detach and gets back an error, and if there's a pending exit event for
the pid we tried to detach, then just ignore the error and pretend the
detach worked fine.

We could possibly check for a pending exit event before sending the
detach packet, however, I believe that it might be possible (in
non-stop mode) for the stop notification to arrive after the detach is
sent, but before gdbserver has started processing the detach.  In this
case we would still need to check for pending stop events after seeing
the detach fail, so I figure there's no point having two checks -- we
just send the detach request, and if it fails, check to see if the
process has already exited.

Testing
=======

In order to test this issue I needed to ensure that the exit event
arrives at the same time as the detach call.  The window of
opportunity for getting the exit to arrive is so small I've never
managed to trigger this in real use -- I originally spotted this issue
while working on another patch, which did manage to trigger this
issue.

However, if we trigger both the exit and the detach from a single
Python function then we never return to GDB's event loop, as such GDB
never processes the exit event, and so the first time GDB gets a
chance to see the exit is during the detach call.  And so that is the
approach I've taken for testing this patch.

Tested-By: Kevin Buettner <kevinb@redhat.com>
Approved-By: Kevin Buettner <kevinb@redhat.com>

[gdb/testsuite] Add wait-for-index-cache in gdb.dwarf2/per-bfd-sharing.exp

If we make writing an index-cache entry very slow by doing this in
index_cache::store:
...
   try
     {
+      sleep (15);
       index_cache_debug ("writing index cache for objfile %s",
   bfd_get_filename (per_bfd->obfd));
...
we run into:
...
FAIL: gdb.dwarf2/per-bfd-sharing.exp: \
  couldn't remove files in temporary cache dir
...

The FAIL happens because there is no index-cache entry in the cache dir.

The problem is that gdb is killed (by gdb_exit) before the index-cache entry
is written.

Fix this by using "maint wait-for-index-cache".

Tested on x86_64-linux.

PR testsuite/30528
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30528

gdb/nat/aarch64-scalable-linux-ptrace.h: Don't include itself

GCC doesn't complain, but it's still wrong.

Automatic date update in version.in

gdb/testsuite: add a clang XFAIL to gdb.python/py-watchpoint.exp

Clang doesn't use CFA information for variable locations. This makes it
so software breakpoints get a false hit when rbp gets popped, causing
a FAIL in gdb.python/py-watchpoint.exp. Since this is nothing wrong with
GDB itself, add an xfail to reduce noise.

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

gdb/testsuite: fix running gdb.python/py-explore-cc with clang

The test gdb.python/py-explore-cc.exp was showing one unexpected
failure. This was due to how clang mapped instructions to lines,
resulting in the inferior seemingly stopping at a different location.

This patch adds a nop line in the relevant location so we don't need to
add XFAILs for existing clang releases, if this gets solved in future
versions.

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

gdbserver: don't leak program name in handle_v_run

I noticed that in handle_v_run (gdbserver/server.cc) we leak
new_program_name (a string) each time GDB starts an inferior, in the
case where GDB passes a program name to gdbserver.

This bug was introduced with this commit:

  commit 7ab2607f97e5deaeae91018edf3ef5b4255a842c
  Date:   Wed Apr 13 17:31:02 2022 -0400

      gdbsupport: make gdb_abspath return an std::string

When gdbserver receives a program name from GDB, this is first placed
into a malloc'd buffer within handle_v_run, and this buffer is then
used in this call:

  program_path.set (new_program_name);

Prior to the above commit this call took ownership of the buffer
passed to it, but now this call uses the buffer to initialise a
std::string, which copies the buffer contents, leaving ownership with
the caller.  So now, after this call (in handle_v_run)
new_program_name still owns a buffer.

At no point in handle_v_run do we free new_program_name, as a result
we are leaking the program name each time GDB starts a remote
inferior.

I could solve this by adding a 'free' call into handle_v_run, but I'd
rather automate the memory management.

So, to this end, I have added a new function in gdbserver/server.cc,
decode_v_run_arg.  This function takes care of allocating the memory
buffer and decoding the vRun packet into the buffer, but returns a
gdb::unique_xmalloc_ptr<char> (or nullptr on error).

Back in handle_v_run I have converted new_program_name to also be a
gdb::unique_xmalloc_ptr<char>.

Now, after we call program_path.set(), the allocated buffer will be
automatically released when it is no longer needed.

It is worth highlighting that within the new decode_v_run_arg
function, I have wrapped the call to hex2bin in a try/catch block.
The hex2bin function can throw an exception if it encounters an
invalid (non-hex) character.  Back in handle_v_run, we have a local
argument new_argv, which is of type std::vector<char *>.  Each
'char *' in this vector is a malloc'd buffer.  If we allow
hex2bin to throw an exception and don't catch it in either
decode_v_run_arg or handle_v_run then we are going to leak memory from
new_argv.

I chose to catch the exception in decode_v_run_arg, this seemed
cleanest, but I'm not sure it really matters, so long as the exception
is caught before we leave handle_v_run.  I am working on a patch that
changes new_argv to automatically manage its memory, but that isn't
ready for posting yet.  I think what I have here would be fine if my
follow on patch never arrives.

Additionally, within the handle_v_run loop I have changed an
assignment of nullptr to new_program_name into an assert.  Previously,
the assignment could only trigger on the first iteration of the loop,
if we had no new program name to assign.  However, new_program_name
always starts as nullptr, so, on the first loop iteration, if we have
nothing to assign to new_program_name, its value must already be
nullptr.

There should be no user visible changes after this commit.

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