kvx: asan: out-of-bounds read

kvx-parse.c:parse_with_restarts does
  if (!tok.insn[tok.begin])
    tok.class_id = -3;
then a little later
  printf_debug (1, "\nEntering rule: %d (Trying to match: (%s)[%d])\n", jump_target,
TOKEN_NAME (CLASS_ID (tok)), CLASS_ID (tok));

This results in a buffer overrun in TOKEN_NAME.  Fix that.

* config/tc-kvx.h (TOKEN_NAME): Check for tok <= 0, not just -1.

kvx bfd signed calculations and _bfd_kvx_elf_resolve_relocation

It is generally a good idea to avoid signed arithmetic on values
extracted from object files, to avoid ubsan warnings on overflow.
This patch replaces some uses of bfd_signed_vma in the kvx backend
with bfd_vma, and removes _bfd_kvx_elf_resolve_relocation, a
do-nothing function.  In the process of making this patch I noticed
some dead code in the GOT entry handling, setting value to
got_entry_addr but using "off" in the _bfd_final_link_relocate call.
Since kvx_calculate_got_entry_vma also returns the GOT offset, I
presume the code is correct, but I've left the dead code and comment
there.

* elfxx-kvx.h (_bfd_kvx_elf_resolve_relocation): Delete.
* elfxx-kvx.c (kvx_signed_overflow): Rewrite using unsigned
arithmetic.
(_bfd_kvx_elf_resolve_relocation): Delete.
* elfnn-kvx.c (kvx_relocate): Update for
_bfd_kvx_elf_resolve_relocation removal.
(elfNN_kvx_final_link_relocate): Likewise.  Don't use a signed
addend.

bfd kvx formatting fixes

Indentation, whitespace and comment fixes.

* elfnn-kvx.c: Formatting.
* elfxx-kvx.c: Formatting.
(elfNN_kvx_final_link_relocate): Correct GOT entry comment.

gdb: bfd_get_symbol_leading_char vs. ""

Some places matching the first char of a string against
bfd_get_symbol_leading_char, which may be zero, didn't check for "".
This could lead to accesses past the end of the string and potential
buffer overruns.  Fix that, and also get rid of a stupid optimisation
in dbxread when looking for "__DYNAMIC" that also might access past
the end of a string.

bfd_get_symbol_leading_char vs. ""

Some places matching the first char of a string against
bfd_get_symbol_leading_char, which may be zero, didn't check for the
string being "".  This patch adds the check to stop accesses past the
end of the string and potential buffer overruns.
The dlltool one was found by oss-fuzz quite a while ago.

bfd/
* cofflink.c (_bfd_coff_link_input_bfd): Ensure a zero
bfd_get_symbol_leading_char doesn't lead to accessing past the
zero string terminator.
* linker.c (bfd_wrapped_link_hash_lookup): Likewise.
(unwrap_hash_lookup): Likewise.
binutils/
* dlltool.c (scan_filtered_symbols): Ensure a zero
bfd_get_symbol_leading_char doesn't lead to accessing past the
zero string terminator.

Automatic date update in version.in

[gdb/build] Work around cgen odr violations

When building gdb with -flto -O2, I run into:
...
opcodes/mep-desc.h:250:14: warning: type 'cgen_operand_type' violates the \
  C++ One Definition Rule [-Wodr]
 typedef enum cgen_operand_type {
              ^
opcodes/or1k-desc.h:624:14: note: an enum with different value name is \
  defined in another translation unit
 typedef enum cgen_operand_type {
              ^
opcodes/mep-desc.h:212:14: warning: type 'cgen_hw_type' violates the C++ One \
  Definition Rule [-Wodr]
 typedef enum cgen_hw_type {
              ^
opcodes/or1k-desc.h:433:14: note: an enum with different value name is \
  defined in another translation unit
 typedef enum cgen_hw_type {
              ^
...

Fix this by making the conflicting type names unique, adding a target-specific
prefix using a define before the include:
...
 #define cgen_operand_type <target-name>_cgen_operand_type
 #define cgen_hw_type  <target-name>_cgen_hw_type
 #include "opcodes/<target-name>-desc.h"
...
and move those defines into a new file cgen-remap.h, similar to how that's
done for yacc in yy-remap.h.

Likewise for targets frv and lm32, the two other targets that include
opcodes/<target-name>-desc.h.

Likewise for more cgen symbols that I got the same warning for when using
-flto-partition=one.

A PR has been filed to take care of this in the opcodes dir instead (PR30758).

Tested on x86_64-linux.

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

Remove value::copy call from gdbpy_get_varobj_pretty_printer

I noticed a call to value::copy in gdbpy_get_varobj_pretty_printer,
and I couldn't figure out why it was there.  I think maybe it came
from the time when value_to_value_object would release values from the
value chain -- but that was removed in commit f3d3bbbc.

This patch removes this call.  Regression tested on x86-64 Fedora 36.

aarch64: Improve naming conventions for A and R-profile architecture

Historically, flags and variables relating to architectural revisions
for the A-profile architecture omitted the trailing `A' such that, for
example, assembling for `-march=armv8.4-a' set the `AARCH64_ARCH_V8_4'
flag in the assembler.

This leads to some ambiguity, since Binutils also targets the
R-profile Arm architecture.  Therefore, it seems prudent to have
everything associated with the A-profile cores end in `A' and likewise
`R' for the R-profile.  Referring back to the example above, the flag
set for `-march=armv8.4-a' is better characterized if labeled
`AARCH64_ARCH_V8_4A'.

The only exception to the rule of appending `A' to variables is found
in the handling of the `AARCH64_FEATURE_V8' macro, as it is the
baseline from which ALL processors derive and should therefore be left
unchanged.

In reflecting the `ARM' architectural nomenclature choices, where we
have `ARM_ARCH_V8A' and `ARM_ARCH_V8R', the choice is made to not have
an underscore separating the numerical revision number and the
A/R-profile indicator suffix.  This has meant that renaming of
R-profile related flags and variables was warranted, thus going from
`.*_[vV]8_[rR]' to `.*_[vV]8[rR]'.

Finally, this is more in line with conventions within GCC and adds consistency
across the toolchain.

gas/ChangeLog:
* gas/config/tc-aarch64.c:
(aarch64_cpus): Reference to arch feature macros updated.
(aarch64_archs): Likewise.

include/ChangeLog:
* include/opcode/aarch64.h:
(AARCH64_FEATURE_V8A): Updated name: V8_A -> V8A.
(AARCH64_FEATURE_V8_1A): A-suffix added.
(AARCH64_FEATURE_V8_2A): Likewise.
(AARCH64_FEATURE_V8_3A): Likewise.
(AARCH64_FEATURE_V8_4A): Likewise.
(AARCH64_FEATURE_V8_5A): Likewise.
(AARCH64_FEATURE_V8_6A): Likewise.
(AARCH64_FEATURE_V8_7A): Likewise.
(AARCH64_FEATURE_V8_8A):Likewise.
(AARCH64_FEATURE_V9A): Likewise.
(AARCH64_FEATURE_V8R): Updated name: V8_R -> V8R.
(AARCH64_ARCH_V8A_FEATURES): Updated name: V8_A -> V8A.
(AARCH64_ARCH_V8_1A_FEATURES): A-suffix added.
(AARCH64_ARCH_V8_2A_FEATURES): Likewise.
(AARCH64_ARCH_V8_3A_FEATURES): Likewise.
(AARCH64_ARCH_V8_4A_FEATURES): Likewise.
(AARCH64_ARCH_V8_5A_FEATURES): Likewise.
(AARCH64_ARCH_V8_6A_FEATURES): Likewise.
(AARCH64_ARCH_V8_7A_FEATURES): Likewise.
(AARCH64_ARCH_V8_8A_FEATURES): Likewise.
(AARCH64_ARCH_V9A_FEATURES): Likewise.
(AARCH64_ARCH_V9_1A_FEATURES): Likewise.
(AARCH64_ARCH_V9_2A_FEATURES): Likewise.
(AARCH64_ARCH_V9_3A_FEATURES): Likewise.
(AARCH64_ARCH_V8A): Updated name: V8_A -> V8A.
(AARCH64_ARCH_V8_1A): A-suffix added.
(AARCH64_ARCH_V8_2A): Likewise.
(AARCH64_ARCH_V8_3A): Likewise.
(AARCH64_ARCH_V8_4A): Likewise.
(AARCH64_ARCH_V8_5A): Likewise.
(AARCH64_ARCH_V8_6A): Likewise.
(AARCH64_ARCH_V8_7A): Likewise.
(AARCH64_ARCH_V8_8A): Likewise.
(AARCH64_ARCH_V9A): Likewise.
(AARCH64_ARCH_V9_1A): Likewise.
(AARCH64_ARCH_V9_2A): Likewise.
(AARCH64_ARCH_V9_3A): Likewise.
(AARCH64_ARCH_V8_R): Updated name: V8_R -> V8R.

opcodes/ChangeLog:
* opcodes/aarch64-opc.c (SR_V8A): Updated name: V8_A -> V8A.
(SR_V8_1A): A-suffix added.
(SR_V8_2A): Likewise.
(SR_V8_3A): Likewise.
(SR_V8_4A): Likewise.
(SR_V8_6A): Likewise.
(SR_V8_7A): Likewise.
(SR_V8_8A): Likewise.
(aarch64_sys_regs): Reference to arch feature macros updated.
(aarch64_pstatefields): Reference to arch feature macros updated.
(aarch64_sys_ins_reg_supported_p): Reference to arch feature macros
updated.
* opcodes/aarch64-tbl.h:
(aarch64_feature_v8_2a): a-suffix added.
(aarch64_feature_v8_3a): Likewise.
(aarch64_feature_fp_v8_3a): Likewise.
(aarch64_feature_v8_4a): Likewise.
(aarch64_feature_fp_16_v8_2a): Likewise.
(aarch64_feature_v8_5a): Likewise.
(aarch64_feature_v8_6a): Likewise.
(aarch64_feature_v8_7a): Likewise.
(aarch64_feature_v8r): Updated name: v8_r-> v8r.
(ARMV8R): Updated name: V8_R-> V8R.
(ARMV8_2A): A-suffix added.
(ARMV8_3A): Likewise.
(FP_V8_3A): Likewise.
(ARMV8_4A): Likewise.
(FP_F16_V8_2A): Likewise.
(ARMV8_5): Likewise.
(ARMV8_6A): Likewise.
(ARMV8_6A_SVE): Likewise.
(ARMV8_7A): Likewise.
(V8_2A_INSN): `A' added to macro symbol.
(V8_3A_INSN): Likewise.
(V8_4A_INSN): Likewise.
(FP16_V8_2A_INSN): Likewise.
(V8_5A_INSN): Likewise.
(V8_6A_INSN): Likewise.
(V8_7A_INSN): Likewise.
(V8R_INSN): Updated name: V8_R-> V8R.

objdump: file name table entry count check

Fuzzers have found that objdump -W takes a really long time if
the entry count uleb is ridiculously large, and format attributes
don't consume data (which doesn't make sense for a table of names).

* dwarf.c (display_formatted_table): Sanity check count of
table entries.

kvx_dis_init

kvx_dis_init currently always returns true, but error conditions do so
by "return -1" which converts to true.  The return status is ignored
anyway, and it doesn't make much sense to error on unexpected arch or
mach:  If print_insn_kvx is called then the atch is known to be kvx,
and it's better to choose some default for a user passing an unknown
mach value rather than segfaulting in decode_insn when env.opc_table
is NULL.

I've chosen the default mach to be bfd_mach_kv3_1, the default in
bfd/cpu-kvx.c, not that it matters very much.  In normal objdump/gdb
usage, info->mach won't be an unexpected value.

* kvx-dis.c (kvx_dis_init): Return void.  Don't error on
unexpected arch or mach.  Default to bfd_mach_kv3_1 for
unknown mach.  Don't clear info->disassembler_options.

kvx-linux config

A misplaced line, resulting in testsuite errors when attempting to use
as -m32.

* config.bfd (kvx-*-linux*): Add targ_selvecs.
(kvx-*-*): Remove targ_selvecs.

Re: kvx: New port.

Add files submitted on the mailing list but somehow not committed.

Automatic date update in version.in

sim: bpf: remove negi, neg32i insns

The BPF virtual machine does not support neg instructions operating on
immediates, and these erroneous instructions were recently removed from
gas.  Remove them from the simulator as well.

bpf: correct neg and neg32 instruction encoding

The neg/neg32 BPF instructions always use BPF_SRC_K (=0) in their header
source bit, despite operating on registers.  If BPF_SRC_X (=1) is set,
the instructions are rejected by the kernel.

Because of this there are also no neg/neg32 instructions which operate
on immediates, so remove them.

bd434cc4d94ec3d2f9fc1e7c00c27b074f962bc1 was a similar fix in the old
CGEN-based port, but was not carried forward in the new port.

include/
* opcode/bpf.h (enum bpf_insn_id): Remove spurious entries
BPF_INSN_NEGI and BPF_INSN_NEG32I.

opcodes/
* bpf-opc.c (bpf_opcodes): Remove erroneous NEGI and NEG32I
instructions.

gas/
* doc/c-bpf.texi (BPF Instructions): Remove erroneous neg and
neg32 instructions operating on immediates.
* testsuite/gas/bpf/alu.s: Adapt accordingly.
* testsuite/gas/bpf/alu.d: Likewise.
* testsuite/gas/bpf/alu-be.d: Likewise
* testsuite/gas/bpf/alu32.s: Likewise.
* testsuite/gas/bpf/alu32.d: Likewise.
* testsuite/gas/bpf/alu32-be.d: Likewise.
* testsuite/gas/bpf/alu-pseudoc.s: Likewise.
* testsuite/gas/bpf/alu-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
* testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu32-be-pseudoc.d: Likewise.

aarch64/sme2: Teach binutils/BFD about the NT_ARM_ZT register set

The Scalable Matrix Extension v2 (SME2) defines a new register, ZT0, that
the Linux Kernel handles through a new NT_ARM_ZT register set.

Teach binutils/BFD about it so that gdb can make use of it for reading
and writing core files.  This also enables readelf/objdump to show the
correct identification for the NT_ARM_ZT register set.

Validated under Fast Models.

aarch64/sme: Core file support

Add required code to support core file dumps with NT_ARM_ZA and NT_ARM_SSVE
register sets in them.

These new register sets are dumped when SME is supported.

bfd_close_all_done bug and bfd_last_cache

bfd_close ought to always call iovec->bclose so that cache_bclose is
called.  If not, bfd_last_cache will be left pointing at freed memory.
This bug was found by oss-fuzz with the trigger being an old bug in
the ia64-vms support.  Given a file of the "wrong" size,
elf64_vms_close_and_cleanup attempted to extend it, leading to an
error since the file was opened read-only by nm.  nm bad_file bad_file
then hit the use-after-free when opening the second file.

commit 8219cab3f8 fixed multiple bugs of this type in bfd_close and
bfd_close_all_done, but didn't go quite far enough.

* elf64-ia64-vms.c (elf64_vms_close_and_cleanup): Don't
attempt to extend read-only files.
* opncls.c (bfd_close_all_done): Always call _close_and_cleanup.

An old bug in the ia64-vms support can be used to tickle another bug
in bfd_close_all_done.  If _close_and_cleanup returns an error,

LoongArch: gas: Fix make check-gas crash

Automatic date update in version.in

Automatic date update in version.in

Placate -Wmissing-declarations in sim/cris

I get a couple of -Wmissing-declarations errors when building the sim.
This happens because an earlier patch added the declarations to a
cgen-generated header, but the recent re-generation then removed them.

This patch fixes the build by adding declarations just before the
definition.  This is normally not best practice, but in this
particular situation it at leat un-breaks the build.

Remove extraneous '%' from sim/cris/local.mk

I saw this warning from make:

Makefile:5043: *** mixed implicit and normal rules: deprecated syntax

I believe this snuck in by error with the recent cgen-related changes.

This patch removes the stray '%' and rebuilds the Makefile.in.  I'm
checking this in.

sim regen

This regenerates sim files.

Tested with the following tools from a recent binutils build in
sim-site-config.exp, plus a few cross compilers.

set AS_FOR_TARGET_AARCH64 "/home/alan/build/gas/aarch64-linux-gnu/gas/as-new"
set LD_FOR_TARGET_AARCH64 "/home/alan/build/gas/aarch64-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_AARCH64 "aarch64-linux-gnu-gcc"
set AS_FOR_TARGET_ARM "/home/alan/build/gas/arm-linux-gnueabi/gas/as-new"
set LD_FOR_TARGET_ARM "/home/alan/build/gas/arm-linux-gnueabi/ld/ld-new"
set CC_FOR_TARGET_ARM "arm-linux-gnueabi-gcc"
set AS_FOR_TARGET_AVR "/home/alan/build/gas/avr-elf/gas/as-new"
set LD_FOR_TARGET_AVR "/home/alan/build/gas/avr-elf/ld/ld-new"
set CC_FOR_TARGET_AVR ""
set AS_FOR_TARGET_BFIN "/home/alan/build/gas/bfin-elf/gas/as-new"
set LD_FOR_TARGET_BFIN "/home/alan/build/gas/bfin-elf/ld/ld-new"
set CC_FOR_TARGET_BFIN ""
set AS_FOR_TARGET_BPF "/home/alan/build/gas/bpf-none/gas/as-new"
set LD_FOR_TARGET_BPF "/home/alan/build/gas/bpf-none/ld/ld-new"
set CC_FOR_TARGET_BPF ""
set AS_FOR_TARGET_CR16 "/home/alan/build/gas/cr16-elf/gas/as-new"
set LD_FOR_TARGET_CR16 "/home/alan/build/gas/cr16-elf/ld/ld-new"
set CC_FOR_TARGET_CR16 ""
set AS_FOR_TARGET_CRIS "/home/alan/build/gas/cris-elf/gas/as-new"
set LD_FOR_TARGET_CRIS "/home/alan/build/gas/cris-elf/ld/ld-new"
set CC_FOR_TARGET_CRIS ""
set AS_FOR_TARGET_D10V "/home/alan/build/gas/d10v-elf/gas/as-new"
set LD_FOR_TARGET_D10V "/home/alan/build/gas/d10v-elf/ld/ld-new"
set CC_FOR_TARGET_D10V ""
set AS_FOR_TARGET_FRV "/home/alan/build/gas/frv-elf/gas/as-new"
set LD_FOR_TARGET_FRV "/home/alan/build/gas/frv-elf/ld/ld-new"
set CC_FOR_TARGET_FRV ""
set AS_FOR_TARGET_FT32 "/home/alan/build/gas/ft32-elf/gas/as-new"
set LD_FOR_TARGET_FT32 "/home/alan/build/gas/ft32-elf/ld/ld-new"
set CC_FOR_TARGET_FT32 ""
set AS_FOR_TARGET_H8300 "/home/alan/build/gas/h8300-elf/gas/as-new"
set LD_FOR_TARGET_H8300 "/home/alan/build/gas/h8300-elf/ld/ld-new"
set CC_FOR_TARGET_H8300 ""
set AS_FOR_TARGET_IQ2000 "/home/alan/build/gas/iq2000-elf/gas/as-new"
set LD_FOR_TARGET_IQ2000 "/home/alan/build/gas/iq2000-elf/ld/ld-new"
set CC_FOR_TARGET_IQ2000 ""
set AS_FOR_TARGET_LM32 "/home/alan/build/gas/lm32-linux-gnu/gas/as-new"
set LD_FOR_TARGET_LM32 "/home/alan/build/gas/lm32-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_LM32 ""
set AS_FOR_TARGET_M32C "/home/alan/build/gas/m32c-elf/gas/as-new"
set LD_FOR_TARGET_M32C "/home/alan/build/gas/m32c-elf/ld/ld-new"
set CC_FOR_TARGET_M32C ""
set AS_FOR_TARGET_M32R "/home/alan/build/gas/m32r-elf/gas/as-new"
set LD_FOR_TARGET_M32R "/home/alan/build/gas/m32r-elf/ld/ld-new"
set CC_FOR_TARGET_M32R ""
set AS_FOR_TARGET_M68HC11 "/home/alan/build/gas/m68hc11-elf/gas/as-new"
set LD_FOR_TARGET_M68HC11 "/home/alan/build/gas/m68hc11-elf/ld/ld-new"
set CC_FOR_TARGET_M68HC11 ""
set AS_FOR_TARGET_MCORE "/home/alan/build/gas/mcore-elf/gas/as-new"
set LD_FOR_TARGET_MCORE "/home/alan/build/gas/mcore-elf/ld/ld-new"
set CC_FOR_TARGET_MCORE ""
set AS_FOR_TARGET_MICROBLAZE "/home/alan/build/gas/microblaze-linux-gnu/gas/as-new"
set LD_FOR_TARGET_MICROBLAZE "/home/alan/build/gas/microblaze-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_MICROBLAZE "microblaze-linux-gnu-gcc"
set AS_FOR_TARGET_MIPS "/home/alan/build/gas/mips-linux-gnu/gas/as-new"
set LD_FOR_TARGET_MIPS "/home/alan/build/gas/mips-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_MIPS "mips-linux-gnu-gcc"
set AS_FOR_TARGET_MN10300 "/home/alan/build/gas/mn10300-elf/gas/as-new"
set LD_FOR_TARGET_MN10300 "/home/alan/build/gas/mn10300-elf/ld/ld-new"
set CC_FOR_TARGET_MN10300 ""
set AS_FOR_TARGET_MOXIE "/home/alan/build/gas/moxie-elf/gas/as-new"
set LD_FOR_TARGET_MOXIE "/home/alan/build/gas/moxie-elf/ld/ld-new"
set CC_FOR_TARGET_MOXIE ""
set AS_FOR_TARGET_MSP430 "/home/alan/build/gas/msp430-elf/gas/as-new"
set LD_FOR_TARGET_MSP430 "/home/alan/build/gas/msp430-elf/ld/ld-new"
set CC_FOR_TARGET_MSP430 ""
set AS_FOR_TARGET_OR1K "/home/alan/build/gas/or1k-linux-gnu/gas/as-new"
set LD_FOR_TARGET_OR1K "/home/alan/build/gas/or1k-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_OR1K ""
set AS_FOR_TARGET_PPC "/home/alan/build/gas/powerpc-linux-gnu/gas/as-new"
set LD_FOR_TARGET_PPC "/home/alan/build/gas/powerpc-linux-gnu/ld/ld-new"
set CC_FOR_TARGET_PPC "powerpc-linux-gnu-gcc"
set AS_FOR_TARGET_PRU "/home/alan/build/gas/pru-elf/gas/as-new"
set LD_FOR_TARGET_PRU "/home/alan/build/gas/pru-elf/ld/ld-new"
set CC_FOR_TARGET_PRU ""
set AS_FOR_TARGET_RISCV "/home/alan/build/gas/riscv32-elf/gas/as-new"
set LD_FOR_TARGET_RISCV "/home/alan/build/gas/riscv32-elf/ld/ld-new"
set CC_FOR_TARGET_RISCV ""
set AS_FOR_TARGET_RL78 "/home/alan/build/gas/rl78-elf/gas/as-new"
set LD_FOR_TARGET_RL78 "/home/alan/build/gas/rl78-elf/ld/ld-new"
set CC_FOR_TARGET_RL78 ""
set AS_FOR_TARGET_RX "/home/alan/build/gas/rx-elf/gas/as-new"
set LD_FOR_TARGET_RX "/home/alan/build/gas/rx-elf/ld/ld-new"
set CC_FOR_TARGET_RX ""
set AS_FOR_TARGET_SH "/home/alan/build/gas/sh-rtems/gas/as-new"
set LD_FOR_TARGET_SH "/home/alan/build/gas/sh-rtems/ld/ld-new"
set CC_FOR_TARGET_SH ""
set AS_FOR_TARGET_ERC32 ""
set LD_FOR_TARGET_ERC32 ""
set CC_FOR_TARGET_ERC32 ""
set AS_FOR_TARGET_V850 "/home/alan/build/gas/v850-elf/gas/as-new"
set LD_FOR_TARGET_V850 "/home/alan/build/gas/v850-elf/ld/ld-new"
set CC_FOR_TARGET_V850 ""

Results both before and after were:
FAIL: crisv10 mem1.ms (execution)
FAIL: crisv10 mem2.ms (execution)
FAIL: crisv32 mem1.ms (execution)
FAIL: crisv32 mem2.ms (execution)
FAIL: microblaze fail.s (execution)
FAIL: microblaze pass.s (execution)
expected passes            5288
unexpected failures        6
expected failures          3
untested testcases         373
unsupported tests          14

sim regen preparation

Regerating sim loses commit 1be79b1ebfad from sim/lm32/cpu.h, a
generated file, so this patch move those declarations to
sim/lm32/sim-main.h.

sim --enable-cgen-maint

I had reason yesterday to want to regenerate configury files which I
do with --enable-maintainer-mode, and added --enable-cgen-maint
accidentally.  The first problem I hit is that sim looks for cgen in a
different directory by default than opcodes, and I had my source
layout set up for opcodes rather than sim.  Fix that by making both
use ../cgen first, then ../../cgen relative to sim/ and opcodes/.  The
next problem was that various sim local.mk files expected generated
sources in the build dir rather than the source dir.  Fix that by
adding $(srcdir) to paths.  Finally, the generated iq2000 files had a
compile error, fixed by the cpu/iq2000.cpu patch.

cpu/
* iq2000.cpu (syscall): Add pc arg.
opcodes/
* configure.ac (cgendir): Default to ../../cgen, but use ../cgen
if found there.
* configure: Regenerate.
sim/m4/
* sim_ac_option_cgen_maint.m4 (cgendir): Look in ../cgen too.
sim/
* cris/local.mk: Add $(srcdir) to paths for regenerated source.
* frv/local.mk: Likewise.
* iq2000/local.mk: Likewise.
* lm32/local.mk: Likewise.
* m32r/local.mk: Likewise.
* or1k/local.mk: Likewise.
* Makefile.in: Regenerate.
* configure: Regenerate.

sim prune_warnings

Remove some of the warnings generated by newer versions of ld.

* testsuite/lib/sim-defs.exp (prune_warnings_extra): New.
Arrange to run it from prune_warnings.

Automatic date update in version.in

Fix off-by-one in call to vector::reserve

While looking at a bug, I noticed what I think is an off-by-one
mistake in a call to vector::reserve.  This code:

      new_args.reserve (args.size ());
      new_args.push_back
(value_from_pointer (lookup_pointer_type (values_type), struct_addr));
      new_args.insert (new_args.end (), args.begin (), args.end ());

... reserves 'size()' entries, but then proceeds to push one extra
one.

This shouldn't have any really bad effects, as insert will grow the
vector.  Still, it seems better to use the correct size if we're going
to bother calling reserve.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30780
Reviewed-by: John Baldwin <jhb@FreeBSD.org>

Merge psympriv.h into psymtab.h

psympriv.h was intended for use by code that created partial symbols.
Now that no generic code needs psymtab.h any more, psympriv.h can be
merged into psymtab.h.

Remove most includes of psymtab.h

I found that most spots including psymtab.h do not need it.  This
patch removes these includes, and also one unnecessary include of
psympriv.h.

x86: remove indirection from bx[] and di_si[]

The longest register name is 3 characters (plus a nul one), so using a
4- or 8-byte pointer to get at it is neither space nor time efficient.
Embed the names right into the array. For PIE this also slightly reduces
the number of base relocations in the final image.

gas: make S_IS_LOCAL() and S_IS_EXTERNAL() exclusive of one another

While they aren't opposites of each other, there also shouldn't be any
symbol for which both return true; both may return false. Therefore
use S_IS_EXTERNAL() in S_IS_LOCAL(), thus subsuming the sanity check
which so far both did alike.

RISC-V: Report "c or zca" for INSN_CLASS_C when error reporting.

bfd/
* elfxx-riscv.c (riscv_multi_subset_supports_ext): Return "c or zca"
rather than "c".

Automatic date update in version.in

C++-ify minidebug.c

I noticed minidebug.c was still using explicit malloc and free, where
a vector would be more automatic.

Reviewed-by: John Baldwin <jhb@FreeBSD.org>

gprofng: Use execvp instead of execv

gp-display-gui (https://savannah.gnu.org/projects/gprofng-gui)
can be installed in a different directory.
In this case, $PATH is used to look up gp-display-text.
execv() does not use $PATH to find the executable.

gprofng/ChangeLog
2023-08-15  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/gp-display-text.cc (reexec): Use execvp instead of execv.

gdb: add inferior-specific breakpoints

This commit extends the breakpoint mechanism to allow for inferior
specific breakpoints (but not watchpoints in this commit).

As GDB gains better support for multiple connections, and so for
running multiple (possibly unrelated) inferiors, then it is not hard
to imagine that a user might wish to create breakpoints that apply to
any thread in a single inferior.  To achieve this currently, the user
would need to create a condition possibly making use of the $_inferior
convenience variable, which, though functional, isn't the most user
friendly.

This commit adds a new 'inferior' keyword that allows for the creation
of inferior specific breakpoints.

Inferior specific breakpoints are automatically deleted when the
associated inferior is removed from GDB, this is similar to how
thread-specific breakpoints are deleted when the associated thread is
deleted.

Watchpoints are already per-program-space, which in most cases mean
watchpoints are already inferior specific.  There is a small window
where inferior-specific watchpoints might make sense, which is after a
vfork, when two processes are sharing the same address space.
However, I'm leaving that as an exercise for another day.  For now,
attempting to use the inferior keyword with a watchpoint will give an
error, like this:

  (gdb) watch a8 inferior 1
  Cannot use 'inferior' keyword with watchpoints

A final note on the implementation: currently, inferior specific
breakpoints, like thread-specific breakpoints, are inserted into every
inferior, GDB then checks once the inferior stops if we are in the
correct thread or inferior, and resumes automatically if we stopped in
the wrong thread/inferior.

An obvious optimisation here is to only insert breakpoint locations
into the specific program space (which mostly means inferior) that
contains either the inferior or thread we are interested in.  This
would reduce the number times GDB has to stop and then resume again in
a multi-inferior setup.

I have a series on the mailing list[1] that implements this
optimisation for thread-specific breakpoints.  Once this series has
landed I'll update that series to also handle inferior specific
breakpoints in the same way.  For now, inferior specific breakpoints
are just slightly less optimal, but this is no different to
thread-specific breakpoints in a multi-inferior debug session, so I
don't see this as a huge problem.

[1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/

[gdb/build] Fix yysymbol_kind_t odr violation

When building gdb with -O2 -flto on openSUSE Tumbleweed (using bison 3.8.2) I
run into:
...
ada-exp.c.tmp:653: warning: type 'yysymbol_kind_t' violates the C++ One \
  Definition Rule [-Wodr]
c-exp.c.tmp:398: note: an enum with different value name is defined in \
  another translation unit
ada-exp.c.tmp:660: note: name 'YYSYMBOL_NULL_PTR' differs from name \
  'YYSYMBOL_COMPLEX_INT' defined in another translation unit
c-exp.c.tmp:405: note: mismatching definition
...

Fix this by renaming to ada_exp_yysymbol_kind_t and likewise for other .y
files.

Tested on x86_64-linux.

PR build/22395
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395

generated bfd files, and kvx regen

The elf32-kvx.c and elf64-kvx.c rules in the bfd makefile are
different to the other similar generated files, and that reminded me
that we need to have $srcdir in the generated #line reference back to
the source for debugging, but don't want it for comments in bfd.pot
(because then bfd.pot will likely reference Nick's source tree).
This patch fixes that by making all the #line use $srcdir by virtue of
using $<, and edits bfd.pot.

I also uniq list of files to remove duplicated elfxx-x86.c, sort lists
of files and regen with our standard automake/autoconf.

* configure: Regenerate.
bfd/
* Makefile.am: Sort various lists of files.  Use $< in #line
directive of generated C files.
(po/SRC-POTFILES.in): uniq SRC_POTFILES.
(po/BLD-POTFILES.in): uniq BFD_POTFILES.
* Makefile.in: Regenerate.
* po/Make-in (bfd.pot): Edit out source dir from comments.
* po/SRC-POTFILES.in: Regenerate.
gas/
* Makefile.in: Regenerate.
* configure: Regenerate.
* po/POTFILES.in: Regenerate.
ld/
* Makefile.am (ALL_64_EMULATION_SOURCES): Sort.
* Makefile.in: Regenerate.

Re: sim frv: Add a missing return value for frvbf_check_acc_range.

Commit f00b50d057 went the wrong way.  As the comment says this
function is only applicable to fr550.  If not fr550 return 1,
meaning we don't have acc restrictions.

[gdb/build, c++20] Handle deprecated std::allocator::construct

When building gdb with -std=c++20, I run into:
...
gdbsupport/default-init-alloc.h:52:12: error: ‘construct’ has not been \
  declared in ‘class std::allocator<unsigned char>’
   52 |   using A::construct;
      |            ^~~~~~~~~
...

Indeed, std::allocator::construct has been deprecated in c++17 and removed in
c++20.

Fix this by using instead std::pmr::polymorphic_allocator for c++20.

Tested on x86_64-linux.

[gdb/build] Return const reference in target_read_auxv

In target_read_auxv we return a copy of an object:
...
gdb::optional<gdb::byte_vector>
target_read_auxv ()
{
  ...
  return info->data;
}
...

Return a const reference instead, saving a copy.

This is exposed by using std::pmr::polymorphic_allocator instead of
std::allocator in default_init_allocator.

Tested on x86_64-linux.

[gdb/build, c++20] Fix invalid conversion in test_symbols

When building gdb with -std=c++20, I run into:
...
gdb/dwarf2/read.c:2709:3: error: invalid conversion from ‘const char8_t*’ to \
  ‘const char*’ [-fpermissive]
 2709 |   u8"u8função",
      |   ^~~~~~~~~~~~
      |   |
      |   const char8_t*
...

Fix this by making the conversion explicit.

Tested on x86_64-linux.

[gdb/build, c++20] Fix deprecated implicit capture of this

When building gdb with -std=c++20 I run into:
...
gdb/ada-lang.c:10713:16: error: implicit capture of ‘this’ via ‘[=]’ is \
  deprecated in C++20 [-Werror=deprecated]
10713 |   auto do_op = [=] (LONGEST x, LONGEST y)
      |                ^
gdb/ada-lang.c:10713:16: note: add explicit ‘this’ or ‘*this’ capture
...

Fix this by using "[this]".

Likewise in two more spots.

Tested on x86_64-linux.

[gdb/build, c++20] Fix DISABLE_COPY_AND_ASSIGN use in ui_out_emit_type

When building gdb with -std=c++20, I run into:
...
include/ansidecl.h:342:9: error: expected unqualified-id before ‘const’
  342 |   TYPE (const TYPE&) = delete;                  \
      |         ^~~~~
gdb/ui-out.h:412:3: note: in expansion of macro ‘DISABLE_COPY_AND_ASSIGN’
  412 |   DISABLE_COPY_AND_ASSIGN (ui_out_emit_type<Type>);
      |   ^~~~~~~~~~~~~~~~~~~~~~~
...

Fix this by using "DISABLE_COPY_AND_ASSIGN (ui_out_emit_type)".

Tested on x86_64-linux.

[gdb/build, c++20] Stop using deprecated is_pod

When building gdb with clang 15 and -std=c++20, I run into:
...
gdbsupport/poison.h:52:11: error: 'is_pod<timeval>' is deprecated: use \
  is_standard_layout && is_trivial instead [-Werror,-Wdeprecated-declarations]
            std::is_pod<T>>
                 ^
...

Fix this by following the suggestion.

Likewise in gdb/unittests/ptid-selftests.c.

Tested on x86_64-linux.

[gdb/build, c++20] Fix Wdeprecated-enum-enum-conversion

When building gdb with clang 15 and -std=c++20, I run into:
...
gdbsupport/common-exceptions.h:203:32: error: arithmetic between different \
  enumeration types ('const enum return_reason' and 'const enum errors') is \
  deprecated [-Werror,-Wdeprecated-enum-enum-conversion]
    size_t result = exc.reason + exc.error;
                    ~~~~~~~~~~ ^ ~~~~~~~~~
...

Fix this by using to_underlying.

Likewise in a few other places.

Tested on x86_64-linux.

[gdb/testsuite] Fix copy-to-remote in gdb.base/vfork-follow-parent.exp

When running test-case gdb.base/vfork-follow-parent.exp, I run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.base/vfork-follow-parent.exp.
ERROR: error copying "vforked-prog": no such file or directory
    while executing
"file copy -force $fromfile $tofile"
    (procedure "gdb_remote_download" line 29)
    invoked from within
"gdb_remote_download target $binfile3"
...

Fix this by:
- making the copy-to-remote conditional on is_remote target, and
- allowing gdb_remote_download to find $binfile3 by using
  standard_output_file.

Also remove unused variable remote_exec_prog.

Tested on x86_64-linux.

gas: tc-sparc.c: undo spurious change in 5be1b787276d2adbe85ae7febc709ca517b62f08

bpf: gas: consolidate handling of immediate overflows

This commit changes the BPF GAS port in order to handle immediate
overflows the same way than the clang BPF assembler:

- For an immediate field of N bits, any written number (positive or
  negative) whose two's complement encoding fit in N its is accepted.
  This means that -2 is the same than 0xffffffe.  It is up to the
  instructions to decide how to interpret the encoded value.

- Immediate fields in jump instructions are no longer relaxed.
  Relaxing to jump instructions with wider range is only performed
  when expressions are involved.

- The manual is updated to document this, and testsuite adapted
  accordingly.

Tested in x86_64-linux-gnu host, bpf-unknown-none target.

gas/ChangeLog:

2023-08-17  Jose E. Marchesi  <jose.marchesi@oracle.com>

* config/tc-bpf.c (check_immediate_overflow): New function.
(encode_insn): Use check_immediate_overflow.
(md_assemble): Do not relax instructions with
constant disp16 fields.
* doc/c-bpf.texi (BPF Instructions): Add note about how numerical
literal values are interpreted for instruction immediate operands.
* testsuite/gas/bpf/disp16-overflow.s: Adapt accordingly.
* testsuite/gas/bpf/jump-relax-jump.s: Likewise.
* testsuite/gas/bpf/jump-relax-jump.d: Likewise.
* testsuite/gas/bpf/jump-relax-jump-be.d: Likewise.
* testsuite/gas/bpf/jump-relax-ja.s: Likewise.
* testsuite/gas/bpf/jump-relax-ja.d: Likewise.
* testsuite/gas/bpf/jump-relax-ja-be.d: Likewise.
* testsuite/gas/bpf/disp16-overflow-relax.l: Likewise.
* testsuite/gas/bpf/imm32-overflow.s: Likewise.
* testsuite/gas/bpf/disp32-overflow.s: Likewise.
* testsuite/gas/bpf/disp16-overflow.l: Likewise.
* testsuite/gas/bpf/disp32-overflow.l: Likewise.
* testsuite/gas/bpf/imm32-overflow.l: Likewise.
* testsuite/gas/bpf/offset16-overflow.l: Likewise.

ld: ld-lib.exp: log failed dump.out contents for debugging

If we're using dump_prog in a test which fails, log the dump.out contents
to ld.log to aid debugging.

This avoids needing to ask reporters to manually run e.g. `objdump` commands
when making bug reports.

PR30722
* ld/testsuite/lib/ld-lib.exp: Log failed dump.out contents to aid
debugging.

Approved-by: Nick Clifton <nickc@redhat.com>
Signed-off-by: Sam James <sam@gentoo.org>

Automatic date update in version.in

[gdb/symtab] Handle self-reference DIE

While working on a dwarf assembly test-case I accidentally created the
following pathological dwarf:
...
 <1><be>: Abbrev Number: 3 (DW_TAG_class_type)
    <bf>   DW_AT_name        : c1
    <c2>   DW_AT_specification: <0xbe>
...
and noticed gdb segfaulting during cooked index creating due to running out of
stack.  This is a regression from gdb-12, where gdb just hung.

Fix this by inhibiting the scan_attributes self-recursion for self-references.

The same test-case with -readnow makes gdb hang, so also fix this in
dwarf2_attr and follow_die_ref.

Note that this doesn't fix the same problems for the more complicated case of:
...
 <1><be>: Abbrev Number: 3 (DW_TAG_class_type)
    <bf>   DW_AT_name        : c1
    <c2>   DW_AT_specification: <0xc6>
 <1><c6>: Abbrev Number: 4 (DW_TAG_class_type)
    <c7>   DW_AT_name        : c2
    <ca>   DW_AT_specification: <0xbe>
...
but the approach for deciding whether to fix pathological dwarf cases is as
per PR27981 comment 3:
...
yes if it is cheap/obvious, and no if it is something complicated or expensive.
...
and at this point I'm not sure whether fixing this will fall in the first
category.

Tested on x86_64-linux.

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

Avoid buffer overflow in ada_decode

A bug report pointed out a buffer overflow in ada_decode, which Keith
helpfully analyzed.  ada_decode had a logic error when the input was
all digits.  While this isn't valid -- and would probably only appear
in fuzzer tests -- it still should be handled properly.

This patch adds a missing bounds check.  Tested with the self-tests in
an asan build.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30639
Reviewed-by: Keith Seitz <keiths@redhat.com>

Fix obvious bug in aggregate expression

I found an obvious bug in Ada aggregate expression handling:

  if (vvo != nullptr)
      error (_("Invalid record component association."));
    name = vvo->get_symbol ()->natural_name ();

Here the code errors when vvo is not null -- and then proceeds to use
vvo.

This hasn't caused a crash because, I believe, there's currently no
way to reach this code in the null case.  However, I'm not really
willing to assert this...

Fixing this shows another bug, which is that due to the way the parser
works, a field name in an aggregate expression might erroneously be
fully qualified if some global variable with the same base name
exists.

The included test case triggers both bugs.  Note that the test
includes a confounding case for array aggregates as well, but as these
are harder to fix, I've left it as kfail.

As this is Ada-specific, and has already been tested internally at
AdaCore, I am checking it in.

Implement DAP module-removed event

DAP specifies an event that should be sent when a module is removed.
This patch implements this.

Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

gdb/testsuite: fix race condition in gdb.python/py-thread-exited.exp

I ran into a test failure on gdb.python/py-thread-exited.c.  The test
creates two threads and then catches the thread exits in Python.  The
test expects the threads to exit in a specific order.

As the test is currently written, it is _likely_, but not guaranteed,
that the threads will exit in the same order they are created, which
is what the test expects.

When running on a loaded system I ran into a case where the threads
exited in the reverse creation order, which caused the test to fail.

I could fix this by having the .exp file not care about the thread
order, or by changing the C file to force the order. I chose the
later, and added a pthread_barrier_t to ensure the threads exit in the
correct order.

There should be no change in what is tested after this commit.

gdb: fix vfork regressions when target-non-stop is off

It was pointed out on the mailing list[1] that after this commit:

  commit b1e0126ec56e099d753c20e91a9f8623aabd6b46
  Date:   Wed Jun 21 14:18:54 2023 +0100

      gdb: don't resume vfork parent while child is still running

the test gdb.base/vfork-follow-parent.exp now has some failures when
run with the native-gdbserver or native-extended-gdbserver boards:

  FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to end of inferior 2 (timeout)
  FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: inferior 1 (timeout)
  FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: print unblock_parent = 1 (timeout)
  FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to break_parent (timeout)

The reason that these failures don't show up when run on the standard
unix board is that the test is only run in the default operating mode,
so for Linux this will be all-stop on top of non-stop.

If we adjust the test script so that it runs in the default mode and
with target-non-stop turned off, then we see the same failures on the
unix board.  This commit includes this change.

The way that the test is written means that it is not (currently)
possible to turn on non-stop mode and have the test still work, so
this commit does not do that.

I have also updated the test script so that the vfork child performs
an exec as well as the current exit.  Exec and exit are the two ways
in which a vfork child can release the vfork parent, so testing both
of these cases is useful I think.

In this test the inferior performs a vfork and the vfork-child
immediately exits.  The vfork-parent will wait for the vfork-child and
then blocks waiting for gdb.  Once gdb has released the vfork-parent,
the vfork-parent also exits.

In the test that fails, GDB sets 'detach-on-fork off' and then runs to
the vfork.  At this point the test tries to just "continue", but this
fails as the vfork-parent is still selected, and the parent can't
continue until the vfork-child completes.  As the vfork-child is
stopped by GDB the parent will never stop once resumed, so GDB refuses
to resume it.

The test script then sets 'schedule-multiple on' and once again
continues.  This time GDB, in theory, resumes both the parent and the
child, the parent will be held blocked by the kernel, but the child
will run until it exits, and which point GDB stops again, this time
with inferior 2, the newly exited vfork-child, selected.

What happens after this in the test script is irrelevant as far as
this failure is concerned.

To understand why the test started failing we should consider the
behaviour of four different cases:

  1. All-stop-on-non-stop before commit b1e0126ec56e,

  2. All-stop-on-non-stop after commit b1e0126ec56e,

  3. All-stop-on-all-stop before commit b1e0126ec56e, and

  4. All-stop-on-all-stop after commit b1e0126ec56e.

Only case #4 is failing after commit b1e0126ec56e, but I think the
other cases are interesting because, (a) they inform how we might fix
the regression, and (b) it turns out the behaviour of #2 changed too
with the commit, but the change was harmless.

For #1 All-stop-on-non-stop before commit b1e0126ec56e, what happens
is:

  1. GDB calls proceed with the vfork-parent selected, as schedule
     multiple is on user_visible_resume_ptid returns -1 (everything)
     as the resume_ptid (see proceed function),

  2. As this is all-stop-on-non-stop, every thread is resumed
    individually, so GDB tries to resume both the vfork-parent and the
    vfork-child, both of which succeed,

  3. The vfork-parent is held stopped by the kernel,

  4. The vfork-child completes (exits) at which point the GDB sees the
     EXITED event for the vfork-child and the VFORK_DONE event for the
     vfork-parent,

  5. At this point we might take two paths depending on which event
     GDB handles first, if GDB handles the VFORK_DONE first then:

     (a) As GDB is controlling both parent and child the VFORK_DONE is
         ignored (see handle_vfork_done), the vfork-parent will be
 resumed,

     (b) GDB processes the EXITED event, selects the (now defunct)
         vfork-child, and stops, returning control to the user.

     Alternatively, if GDB selects the EXITED event first then:

     (c) GDB processes the EXITED event, selects the (now defunct)
         vfork-child, and stops, returning control to the user.

     (d) At some future time the user resumes the vfork-parent, at
         which point the VFORK_DONE is reported to GDB, however, GDB
 is ignoring the VFORK_DONE (see handle_vfork_done), so the
 parent is resumed.

For case #2, all-stop-on-non-stop after commit b1e0126ec56e, the
important difference is in step (2) above, now, instead of resuming
both the vfork-parent and the vfork-child, only the vfork-child is
resumed.  As such, when we get to step (5), only a single event, the
EXITED event is reported.

GDB handles the EXITED just as in (5)(c), then, later, when the user
resumes the vfork-parent, the VFORKED_DONE is immediately delivered
from the kernel, but this is ignored just as in (5)(d), and so,
though the pattern of when the vfork-parent is resumed changes, the
overall pattern of which events are reported and when, doesn't
actually change.  In fact, by not resuming the vfork-parent, the order
of events (in this test) is now deterministic, which (maybe?) is a
good thing.

If we now consider case #3, all-stop-on-all-stop before commit
b1e0126ec56e, then what happens is:

  1. GDB calls proceed with the vfork-parent selected, as schedule
     multiple is on user_visible_resume_ptid returns -1 (everything)
     as the resume_ptid (see proceed function),

  2. As this is all-stop-on-all-stop, the resume is passed down to the
     linux-nat target, the vfork-parent is the event thread, while the
     vfork-child is a sibling of the event thread,

  3. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
     for all threads, this causes the vfork-child to be resumed.  Then
     in linux_nat_target::resume, the event thread, the vfork-parent,
     is also resumed.

  4. The vfork-parent is held stopped by the kernel,

  5. The vfork-child completes (exits) at which point the GDB sees the
     EXITED event for the vfork-child and the VFORK_DONE event for the
     vfork-parent,

  6. We are now in a situation identical to step (5) as for
     all-stop-on-non-stop above, GDB selects one of the events to
     handle, and whichever we select the user sees the correct
     behaviour.

And so, finally, we can consider #4, all-stop-on-all-stop after commit
b1e0126ec56e, this is the case that started failing.

We start out just like above, in proceed, the resume_ptid is
-1 (resume everything), due to schedule multiple being on.  And just
like above, due to the target being all-stop, we call
proceed_resume_thread_checked just once, for the current thread,
which, remember, is the vfork-parent thread.

The change in commit b1e0126ec56e was to avoid resuming a vfork-parent
thread, read the commit message for the justification for this change.

However, this means that GDB now rejects resuming the vfork-parent in
this case, which means that nothing gets resumed!  Obviously, if
nothing resumes, then nothing will ever stop, and so GDB appears to
hang.

I considered a couple of solutions which, in the end, I didn't go
with, these were:

  1. Move the vfork-parent check out of proceed_resume_thread_checked,
     and place it in proceed, but only on the all-stop-on-non-stop
     path, this should still address the issue seen in b1e0126ec56e,
     but would avoid the issue seen here.  I rejected this just
     because it didn't feel great to split the checks that exist in
     proceed_resume_thread_checked like this,

  2. Extend the condition in proceed_resume_thread_checked by adding a
     target_is_non_stop_p check.  This would have the same effect as
     idea 1, but leaves all the checks in the same place, which I
     think would be better, but this still just didn't feel right to
     me, and so,

What I noticed was that for the all-stop-on-non-stop, after commit
b1e0126ec56e, we only resumed the vfork-child, and this seems fine.
The vfork-parent isn't going to run anyway (the kernel will hold it
back), so if feels like we there's no harm in just waiting for the
child to complete, and then resuming the parent.

So then I started looking at follow_fork, which is called from the top
of proceed.  This function already has the task of switching between
the parent and child based on which the user wishes to follow.  So, I
wondered, could we use this to switch to the vfork-child in the case
that we are attached to both?

Turns out this is pretty simple to do.

Having done that, now the process is for all-stop-on-all-stop after
commit b1e0126ec56e, and with this new fix is:

  1. GDB calls proceed with the vfork-parent selected, but,

  2. In follow_fork, and follow_fork_inferior, GDB switches the
     selected thread to be that of the vfork-child,

  3. Back in proceed user_visible_resume_ptid returns -1 (everything)
     as the resume_ptid still, but now,

  4. When GDB calls proceed_resume_thread_checked, the vfork-child is
     the current selected thread, this is not a vfork-parent, and so
     GDB allows the proceed to continue to the linux-nat target,

  5. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
     for all threads, this does not resume the vfork-parent (because
     it is a vfork-parent), and then the vfork-child is resumed as
     this is the event thread,

At this point we are back in the same situation as for
all-stop-on-non-stop after commit b1e0126ec56e, that is, the
vfork-child is resumed, while the vfork-parent is held stopped by
GDB.

Eventually the vfork-child will exit or exec, at which point the
vfork-parent will be resumed.

[1] https://inbox.sourceware.org/gdb-patches/3e1e1db0-13d9-dd32-b4bb-051149ae6e76@simark.ca/

kvx: New port.

aarch64: Enable Cortex-A720 CPU

This patch adds support for the Cortex-A720 CPU to binutils.

bfd/ChangeLog:

* cpu-aarch64.c: Add Cortex-A720.

gas/ChangeLog:

* NEWS: Update docs.
* config/tc-aarch64.c: Add Cortex-A720.
* doc/c-aarch64.texi: Update docs.
* testsuite/gas/aarch64/cpu-cortex-a720.d: New test.

gdb, infcmd: support jump command in multi-inferior case

Fixes the issue where jump failed if multiple inferiors run the same
source.

See the below example

    $ gdb -q ./simple
    Reading symbols from ./simple...
    (gdb) break 2
    Breakpoint 1 at 0x114e: file simple.c, line 2.
    (gdb) run
    Starting program: /temp/simple

    Breakpoint 1, main () at simple.c:2
    2         int a = 42;
    (gdb) add-inferior
    [New inferior 2]
    Added inferior 2 on connection 1 (native)
    (gdb) inferior 2
    [Switching to inferior 2 [<null>] (<noexec>)]
    (gdb) info inferiors
      Num  Description       Connection           Executable
      1    process 6250      1 (native)           /temp/simple
    * 2    <null>            1 (native)
    (gdb) file ./simple
    Reading symbols from ./simple...
    (gdb) run
    Starting program: /temp/simple

    Thread 2.1 "simple" hit Breakpoint 1, main () at simple.c:2
    2         int a = 42;
    (gdb) info inferiors
      Num  Description       Connection           Executable
      1    process 6250      1 (native)           /temp/simple
    * 2    process 6705      1 (native)           /temp/simple
    (gdb) jump 3
    Unreasonable jump request
    (gdb)

In this example, jump fails because the debugger finds two different
locations, one for each inferior.

Solution is to limit the search to the current program space.

This is done by having the jump_command function use
decode_line_with_current_source rather than
decode_line_with_last_displayed, which makes sense,
the *_current_source function always looks up a location based on the
current thread's location -- if a user is asking the current thread to
jump, then surely their destination should be relative to where the
current thread is located.

Then, inside decode_line_with_current_source, the call to
decode_line_1 is updated to pass through the current program_space,
which will limit the returned locations to those in the current
program space.

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

Automatic date update in version.in

Mention process_stratum in inferior::priv comment

From what I can tell, inferior::priv is reserved for the
process_stratum target.  It seems to me that it has to be, because
currenlty only such targets use it, and if a target at another stratum
started using this field, then conflicts could occur.  This patch
documents this.

Reviewed-by: John Baldwin <jhb@FreeBSD.org>

Updated Russian translation for the bfd directory

RISC-V: Make T-Head testing pattern more generic

On some T-Head vendor extensions, we test against the constant
18446744073709551615 (2**64-1) to detect invalid immediate errors on -1.
However, it heavily depends on the fact that the value used to print
immediate value is a 64-bit unsigned type and this constant is not (and
should not be) important (we just want to know that -1 is not valid).

This commit replaces all such occurrences of 18446744073709551615 with
a more generic regular expression.

gas/ChangeLog:

* testsuite/gas/riscv/x-thead-ba-fail.l: Replace
18446744073709551615 with generic regular expression.
* testsuite/gas/riscv/x-thead-bb-fail.l: Likewise.
* testsuite/gas/riscv/x-thead-bs-fail.l: Likewise.
* testsuite/gas/riscv/x-thead-fmemidx-fail.l: Likewise.
* testsuite/gas/riscv/x-thead-memidx-fail.l: Likewise.
* testsuite/gas/riscv/x-thead-mempair-fail.l: Likewise.

RISC-V: Make "fli.h" available to 'Zvfh' + 'Zfa'

The documentation of the 'Zfa' extension states that "fli.h" is available
"if the Zfh or Zvfh extension is implemented" (both the latest and the
oldest editions are checked).

This fact was not reflected in Binutils ('Zvfh' implies 'Zfhmin', not full
'Zfh' extension and "fli.h" required 'Zfh' and 'Zfa' extensions).
This commit makes "fli.h" also available when both 'Zfa' and 'Zvfh'
extensions are implemented.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add new
instruction class handling.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* testsuite/gas/riscv/zfa-zvfh.s: New test.
* testsuite/gas/riscv/zfa-zvfh.d: Ditto.

include/ChangeLog:

* opcode/riscv.h (enum riscv_insn_class): Add new instruction
class.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Change instruction class of "fli.h"
from INSN_CLASS_ZFH_AND_ZFA to new INSN_CLASS_ZFH_OR_ZVFH_AND_ZFA.

RISC-V: Add support for the 'Zihintntl' extension

This commit adds 'Zihintntl' extension and its hint instructions.

This is based on:
<https://github.com/riscv/riscv-isa-manual/commit/0dc91f505e6da7791d5a733c553e6e2506ddcab5>,
the first ISA Manual noting that the 'Zihintntl' extension is ratified.

Note that compressed 'Zihintntl' hints require either 'C' or
'Zca' extension.

Co-authored-by: Nelson Chu <nelson@rivosinc.com>
bfd/ChangeLog:

* elfxx-riscv.c (riscv_supported_std_z_ext): Add 'Zihintntl'
standard hint 'Z' extension.
(riscv_multi_subset_supports): Support new instruction classes.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* testsuite/gas/riscv/zihintntl.s: New test for 'Zihintntl'
including auto-compression without C prefix and explicit C prefix.
* testsuite/gas/riscv/zihintntl.d: Likewise.
* testsuite/gas/riscv/zihintntl-na.d: Likewise.
* testsuite/gas/riscv/zihintntl-base.s: New test for correspondence
between 'Zihintntl' and base 'I' or 'C' instructions.
* testsuite/gas/riscv/zihintntl-base.d: Likewise.

include/ChangeLog:

* opcode/riscv.h (enum riscv_insn_class): Add new instruction
classes: INSN_CLASS_ZIHINTNTL and INSN_CLASS_ZIHINTNTL_AND_C.
(MASK_NTL_P1, MATCH_NTL_P1, MASK_NTL_PALL,
MATCH_NTL_PALL, MASK_NTL_S1, MATCH_NTL_S1, MASK_NTL_ALL,
MATCH_NTL_ALL, MASK_C_NTL_P1, MATCH_C_NTL_P1, MASK_C_NTL_PALL,
MATCH_C_NTL_PALL, MASK_C_NTL_S1, MATCH_C_NTL_S1, MASK_C_NTL_ALL,
MATCH_C_NTL_ALL): New.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Add instructions from the
'Zihintntl' extension.

RISC-V: remove indirection from register tables

The longest register name is 4 characters (plus a nul one), so using a
4- or 8-byte pointer to get at it is neither space nor time efficient.
Embed the names right into the array. For PIE this also reduces the
number of base relocations in the final image.

To avoid old gcc, when generating 32-bit code, bogusly warning about
bounds being exceeded in the code processing Cs/Cw, Ct/Cx, and CD,
an adjustment to EXTRACT_BITS() is needed: This macro shouldn't supply
a 64-bit value, and it also doesn't need to - all operand fields to
date are far more narrow than 32 bits. This in turn allows dropping a
number of casts elsewhere.

PPC: remove indirection from struct pd_reg

The longest register name is 5 characters (plus a nul one), so using a
4- or 8-byte pointer to get at it is neither space nor time efficient.
Embed the names right into the array. For PIE this also reduces the
number of base relocations in the final image.

Automatic date update in version.in

[gdb/build] Fix YYSTYPE and yyalloc odr violation

When building gdb with -O2 -flto I run into:
...
ada-exp.c.tmp:576:7: error: type ‘union YYSTYPE’ violates the C++ One \
  Definition Rule [-Werror=odr]
...

Fix this by renaming to ada_exp_YYSTYPE and likewise for other .y files.

Likewise for yyalloc.

Tested on x86_64-linux.  Also tested with byacc rather than bison on
suggestion of Tom Tromey.

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

fbsd-nat: Stop a process if it is running before killing it.

In addition, detach from any child processes implicitly attached to by
the kernel due to fork following that have not yet been processed by
GDB's core.

fbsd-nat: Fix thread_alive against a running thread.

FreeBSD's ptrace fails requests with EBUSY against a running process.
Report that the thread is alive instead of dead if ptrace fails with
EBUSY.

This fixes an internal error in the gdb.threads/detach-step-over.exp
test where one process was detached while a thread in a second process
was being stepped.  The core incorrectly assumed the stepping thread
had vanished and discarded the pending stepping state.  When the
thread later reported a SIGTRAP from completing the step, this
triggered an assertion.

fbsd-nat: Fix several issues with detaching.

- Detach from any child processes implicitly attached to by the kernel
  due to fork following that have not yet been processed by GDB's
  core.

- Delete breakpoints before detaching.

  inf-ptrace::detach does not do this (somewhat surprisingly), so add
  an override to remove breakpoints from a process before detaching
  from it.

  This also requires explicitly draining any pending SIGTRAP events
  for software breakpoints before detaching.  In particular, threads
  may need their PC adjusted due to the software breakpoint before
  being resumed after detach.  On more modern systems using the si_code
  from SIGTRAP to identify software breakpoint traps, the PC is adjusted
  in ::wait_1 as a side effect of parsing the event.  To support older
  kernels, ::detach fixes up the PC for any SIGTRAP stop whose potential
  new PC matches an existing software breakpoint.

fbsd-nat: Fix resuming and waiting with multiple processes.

I did not fully understand the requirements of multiple process
support when I enabled it previously and several parts were broken.
In particular, the resume method was only resuming a single process,
and wait was not stopping other processes when reporting an event.

To support multiple running inferiors, add a new per-inferior
structure which trackes the number of existing and running LWPs for
each process.  The structure also stores a ptid_t describing the
set of LWPs currently resumed for each process.

For the resume method, iterate over all non-exited inferiors resuming
each process matching the passed in ptid rather than only resuming the
current inferior's process for a wildcard ptid.  If a resumed process
has a pending event, don't actually resume the process, but other
matching processes without a pending event are still resumed in case
the later call to the wait method requests an event from one of the
processes without a pending event.

For the wait method, stop other running processes before returning an
event to the core.  When stopping a process, first check to see if an
event is already pending.  If it is, queue the event to be reported
later.  If not, send a SIGSTOP to the process and wait for it to stop.
If the event reported by the wait is not for the SIGSTOP, queue the
event and remember to ignore a future SIGSTOP event for the process.

Note that, unlike the Linux native target, entire processes are
stopped rather than individual LWPs.  In FreeBSD one can only wait on
processes (via pid), not for an event from a specific thread.

Other changes in this commit handle bookkeeping for the per-inferior
data such as migrating the data to the new inferior in the follow_exec
method.  The per-inferior data is created in the attach,
create_inferior, and follow_fork methods.

fbsd-nat: Defer any ineligible events reported by wait.

If wait_1 finds an event for a thread or process that does not match
the set of threads and processes previously resumed, defer the event.
If the event is for a specific thread, suspend the thread and continue
the associated process before waiting for another event.

One specific example of such an event is if a thread is created while
another thread in the same process hits a breakpoint.  If the second
thread's event is reported first, the target resume method does not
yet "know" about the new thread and will not suspend it via
PT_SUSPEND.  When wait is called, it will probably return the event
from the first thread before the result of the step from second
thread.  This is the case reported in PR 21497.

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

fbsd-nat: Add a list of pending events.

The m_pending_events list stores a queue of deferred events that might
be reported by the next call to the target's wait method.  The set of
events that are eligible is filtered by the ptid passed to resume.

For now this just replaces the list of vfork_done events.  A
subsequent commit will reuse this to store other events.

Remove alloca from osabi.c

I noticed that the call to alloca in osabi.c can be replaced with a
statically-sized buffer, because some code just before the declaration
ensures that the length is bounded.

Reviewed-by: John Baldwin <jhb@FreeBSD.org>

[gdb/build] Fix struct token odr violation

When building gdb with -O2 -flto I run into:
...
/data/vries/gdb/src/gdb/c-exp.y:2450:8: warning: type 'struct token' \
  violates the C++ One Definition Rule [-Wodr]
 struct token
        ^
/data/vries/gdb/src/gdb/d-exp.y:939:8: note: a different type is defined in \
  another translation unit
 struct token
        ^
...

Fix this by renaming to c_token and d_token.

Likewise in:
- fortran-exp.y, renaming to f_token,
- go-exp.y, renaming to go_token, and
- p-exp.y, renaming to p_token.

Tested on x86_64-linux.

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

[gdb/build] Fix struct token_and_value odr violation

When build gdb with -O2 -flto I run into:
...
gdb/c-exp.y:3003:8: warning: type 'struct token_and_value' violates the C++ \
  One Definition Rule [-Wodr]
 struct token_and_value
        ^
gdb/d-exp.y:1310:8: note: a different type is defined in another translation \
  unit
 struct token_and_value
        ^
...

Fix this by renaming to c_token_and_value and d_token_and_value.

Likewise in gdb/go-exp.y, renaming to go_token_and_value.

Tested on x86_64-linux.

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

[gdb/build] Fix enum param_types odr violation

When building gdb with -O2 -flto, I run into:
...
gdb/guile/scm-param.c:121:6: warning: type 'param_types' violates the C++ \
  One Definition Rule [-Wodr]
 enum param_types
      ^
gdb/python/py-param.c:33:6: note: an enum with different value name is \
  defined in another translation unit
 enum param_types
      ^
...

Fix this by renaming to enum scm_param_types and py_param_types.

Tested on x86_64-linux.

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

[gdb/build] Remove superfluous variable param_types in gdb/python/py-param.c

In gdb/python/py-param.c we have:
...
enum param_types
{
  ...
}
param_types;
...
which declares both an enum param_types, and an unused variable param_types.

Fix this by removing the variable.

Tested on x86_64-linux.

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

[gdb] Fix maint print symbols/psymbols help text

Consider the help text of "maint print symbols":
...
(gdb) help maint print symbols
Print dump of current symbol definitions.
Usage: mt print symbols [-pc ADDRESS] [--] [OUTFILE]
       mt print symbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE]
Entries in the full symbol table are dumped to file OUTFILE,
or the terminal if OUTFILE is unspecified.
If ADDRESS is provided, dump only the file for that address.
If SOURCE is provided, dump only that file's symbols.
If OBJFILE is provided, dump only that file's minimal symbols.
...
and "maint print psymbols":
...
(gdb) help maint print psymbols
Print dump of current partial symbol definitions.
Usage: mt print psymbols [-objfile OBJFILE] [-pc ADDRESS] [--] [OUTFILE]
       mt print psymbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE]
Entries in the partial symbol table are dumped to file OUTFILE,
or the terminal if OUTFILE is unspecified.
If ADDRESS is provided, dump only the file for that address.
If SOURCE is provided, dump only that file's symbols.
If OBJFILE is provided, dump only that file's minimal symbols.
...

The OBJFILE lines mistakingly mention minimal symbols.

Fix this by reformulating as "dump only that object file's symbols".

Also make the ADDRESS lines more clear by using the formulation: "dump only
the symbols for the file with code at that address".

Tested on x86_64-linux.

Co-Authored-By: Eli Zaretskii <eliz@gnu.org>
PR gdb/30742
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30742

ld: Build libpr23169a.so with -z lazy

pr23169b test only works with lazy binding.  To work with linker which
disables lazy binding by default, build pr23169b binaries with -z lazy.

PR ld/30698
* ld-ifunc/ifunc.exp: Build pr23169b binaries with -z lazy.

Remove fall-back prune_warnings

No one should be using versions of dejagnu without prune_warnings,
which was available in 1996 (dejagnu-1.3).

binutils/
* testsuite/lib/binutils-common.exp: Remove fallback prune_warnings.
gas/
* testsuite/lib/gas-defs.exp: Remove fallback prune_warnings.

Re: PR30715, VAX: md_create_long_jump

Tidy comment formatting.

ld: fix relocatable, retain7a target pattens for HPPA

Fix issue reported by Dave and Alan.

Put back the old pattern for hppa-*-linux* and add hppa[12]*-*-linux* to cover
Gentoo's hppa1.1 and hppa2.0 without including hppa64 inadvertently like I did
before.

ld/
PR 30733
PR 30734
* ld/testsuite/ld-elf/relocatable.d: Use better pattern to exclude hppa64
          but include hppa1.1, hppa2.0.
* ld/testsuite/ld-elf/retain7a.d: Ditto.

Fixes: 0e339f6b4f2df25ed351cb94dc7fe16868626f49
Fixes: e3b66187192ce6840df283c00f6395bb0ff15cf5
Signed-off-by: Sam James <sam@gentoo.org>

Automatic date update in version.in

[gdb/symtab] Don't deduplicate variables in gdb-index

When running test-case gdb.python/py-symbol.exp with target board
cc-with-gdb-index, we run into:
...
(gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
1^M
(gdb) FAIL: gdb.python/py-symbol.exp: print (len (gdb.lookup_static_symbols ('rr')))
...

[ Note that the test-case contains rr in both py-symtab.c:
...
static int __attribute__ ((used)) rr = 42; /* line of rr */
...
and py-symtab-2.c:
...
static int __attribute__ ((used)) rr = 99; /* line of other rr */
... ]

This passes with gdb-12-branch, and fails with gdb-13-branch.

AFAIU the current code in symtab_index_entry::minimize makes the assumption
that it's fine to store only one copy of rr in the gdb-index, because
"print rr" will only ever print one, and always the same.

But that fails to recognize that gdb supports gdb.lookup_static_symbols, which
returns a list of variables rather than the first one.

In other words, the current approach breaks feature parity between cooked
index and gdb-index.

Note btw that also debug-names has both instances:
...
[  5] #00597969 rr:
        <4> DW_TAG_variable DW_IDX_compile_unit=3 DW_IDX_GNU_internal=1
        <4> DW_TAG_variable DW_IDX_compile_unit=4 DW_IDX_GNU_internal=1
...

Fix this in symtab_index_entry::minimize, by not deduplicating variables.

Tested on x86_64-linux, with target boards unix and cc-with-gdb-index.

Reviewed-by: Kevin Buettner <kevinb@redhat.com>
PR symtab/30720
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30720

gprofng: pass gprofng location to gp-display-gui

gprofng GUI can be installed to the other directory.
In this case, $PATH is used to find gp-display-gui from gprofng
and option --gprofngdir is passed to gp-display-gui.

gprofng/ChangeLog
2023-08-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/gprofng.cc (Gprofng::exec_cmd): Add option --gprofngdir.

gprofng: fix typos in get_realpath() and check_executable()

gprofng/ChangeLog
2023-08-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/Application.cc (Application::get_realpath): Fix typo.
* src/checks.cc (collect::check_executable): Likewise.

Automatic date update in version.in

Re: gdb: warn unused result for bfd IO functions

Add a missing return statement.

PR30715, VAX: md_create_long_jump

PR 30715
* config/tc-vax.c (md_create_long_jump): Use pc-relative addressing.
* testsuite/gas/vax/broken_word.d,
* testsuite/gas/vax/broken_word.s: New test.
* testsuite/gas/vax/vax.exp: Run it.

gdbserver: Reinstall software single-step breakpoints in resume_stopped_resumed_lwps

At the moment, while performing a software single-step, gdbserver fails
to reinsert software single-step breakpoints for a LWP when
interrupted by a signal in another thread.  This commit fixes this
problem by reinstalling software single-step breakpoints in
linux_process_target::resume_stopped_resumed_lwps in
gdbserver/linux-low.cc.

This bug was discovered due to a failing assert in maybe_hw_step()
in gdbserver/linux-low.cc.  Looking at the backtrace revealed
that the caller was linux_process_target::resume_stopped_resumed_lwps.
I was uncertain whether the assert should still be valid when called
from that method, so I tried hoisting the assert from maybe_hw_step
to all callers except resume_stopped_resumed_lwps.  But running the
new test case, described below, showed that merely eliminating the
assert for this case was NOT a good fix - a study of the log file for
the test showed that the single-step operation failed to occur.
Instead GDB (via gdbserver) stopped at the next breakpoint that was
hit.

Zhiyong Yan had proposed a fix which resinserted software single-step
breakpoints, albeit at a different location in linux-low.cc.  Testing
revealed that, while running gdb.threads/pending-fork-event-detach,
the executable associated with that test would die due to a SIGTRAP
after the test program was detached.  Examination of the core file(s)
showed that a breakpoint instruction had been left in program memory.
Test results were otherwise very good, so Zhiyong was definitely on
the right track!

This commit causes software single-step breakpoint(s) to be inserted
before the call to maybe_hw_step in resume_stopped_resumed_lwps.  This
will cause 'has_single_step_breakpoints (thread)' to be true, so that
the assert in maybe_hw_step...

      /* GDBserver must insert single-step breakpoint for software
 single step.  */
      gdb_assert (has_single_step_breakpoints (thread));

...will no longer fail.  And better still, the single-step breakpoints
are reinstalled, so that stepping will actually work, even when
interrupted.

The C code for the test case was loosely adapted from the reproducer
provided in Zhiyong's bug report for this problem.  The .exp file was
copied from next-fork-other-thread.exp and then tweaked slightly.  As
noted in a comment in next-fork-exec-other-thread.exp, I had to remove
"on" from the loop for non-stop as it was failing on all architectures
(including x86-64) that I tested.  I have a feeling that it ought to
work, but this can be investigated separately and (re)enabled once it
works.  I also increased the number of iterations for the loop running
the "next" commands.  I've had some test runs which don't show the bug
until the loop counter exceeded 100 iterations.  The C file for the
new test uses shorter delays than next-fork-other-thread.c though, so
it doesn't take overly long (IMO) to run this new test.

Running the new test on a Raspberry Pi w/ a 32-bit (Arm) kernel and
userland using a gdbserver build without the fix in this commit shows
the following results:

FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=12: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=9: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=18: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=3: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=11: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=3: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=47: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=57: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=10: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to break here

=== gdb Summary ===

 # of unexpected core files 12
 # of expected passes 3011
 # of unexpected failures 14

Each of the 12 core files were caused by the failed assertion in
maybe_hw_step in linux-low.c.  These correspond to 12 of the
unexpected failures.

When the tests are run using a gdbserver build which includes the fix
in this commit, the results are significantly better, but not perfect:

FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=143: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=25: next to other line

=== gdb Summary ===

 # of expected passes 10178
 # of unexpected failures 2

I think that the two remaining failures are due to some different
problem.  They are also racy - I've seen runs with no failures or only
one failure, but never more than two.  Also, those runs were conducted
with the loop count in next-fork-exec-other-thread.exp set to 200.
During his testing of this fix and the new test case, Luis Machado
found that this test was taking a long time and asked about ways to
speed it up.  I then conducted additional tests in which I gradually
reduced the loop count, timing each one, also noting the number of
failures.  With the loop count set to 30, I found that I could still
reliably reproduce the failures that Zhiyong reported (in which, with
the proper settings, core files are created).  But, with the loop
count set to 30, the other failures noted above were much less likely
to show up.  Anyone wishing to investigate those other failures should
set the loop count back up to 200.

Running the new test on x86-64 and aarch64, both native and
native-gdbserver shows no failures.

Also, I see no regressions when running the entire test suite for
armv7l-unknown-linux-gnueabihf (i.e.  the Raspberry Pi w/ 32-bit
kernel+userland) with --target_board=native-gdbserver.  Additionally,
using --target_board=native-gdbserver, I also see no regressions for
the entire test suite for x86-64 and aarch64 running Fedora 38.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30387
Co-Authored-By: Zhiyong Yan <zhiyong.yan@windriver.com>
Tested-By: Zhiyong Yan <zhiyong.yan@windriver.com>
Tested-By: Luis Machado <luis.machado@arm.com>

regen config

This regenerates config files changed by the previous 44 commits.
Note that subject lines in these commits mostly match the gcc git
originating commit.

toplevel: Substitute GDCFLAGS instead of using CFLAGS

r14-2875-g1ed21e23d6d4da ("Use substituted GDCFLAGS") already
implemented this change, but only on the generated file rather than in
the template it is generated from.

* Makefile.tpl: Substitute @GDCFLAGS@ instead of using
$(CFLAGS).

Use substituted GDCFLAGS

Use the substituted value for GCDFLAGS instead of hardcoding $(CFLAGS) so
that the subdir configure scripts use the configured value.

* configure.ac (GDCFLAGS): Set default from ${CFLAGS}.