gdb: link executables with libtool

This patch changes the GDB build system in order to use libtool to
link the several built executables.  This makes it possible to refer
to libtool libraries (.la files) in CLIBS.

As an application of the above,

  BFD              now refers to ../libbfd/libbfd.la
  OPCODES          now refers to ../opcodes/libopcodes.la
  LIBBACKTRACE_LIB now refers to ../libbacktrace/libbacktrace.la
  LIBCTF           now refers to ../libctf/libctf.la

NOTE1: The addition of libtool adds a few new configure-time options
       to GDB.  Among these, --enable-shared and --disable-shared, which were
       previously ignored.  Now GDB shall honor these options when linking,
       picking up the right version of the referred libtool libraries
       automagically.

NOTE2: I have not tested the insight build.

NOTE3: For regenerating configure I used an environment with Autoconf
       2.69 and Automake 1.15.1.  This should match the previously
       used version as announced in the configure script.

NOTE4: Now the installed shared objects libbfd.so, libopcodes.so and
       libctf.so are used by gdb if binutils is installed with
       --enable-shared.

Testing performed:

- --enable-shared and --disable-shared (the default in binutils) work
  as expected: the linked executables link with the archive or shared
  libraries transparently.

- Makefile.in modified for EXEEXT = .exe.  It installs the binaries
  just fine.  The installed gdb.exe runs fine.

- Native build regtested in x86_64. No regressions found.

- Cross build for aarch64-linux-gnu built to exercise
  program_transform_name and friends.  The installed
  aarch64-linux-gnu-gdb runs fine.

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

gdb/testsuite: use a more unique name in gdb.mi/mi-breakpoint-multiple-locations.exp

I see failures in this test, due to the function name "add" being too
generic, and unexpected breakpoint locations being found in my
libstdc++, such as (wrapped for readability):

    {
   number="2.4",enabled="y",addr="0x00007ffff7d67e68",
   func="(anonymous namespace)::fast_float::bigint::add",
file="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h",
fullname="/usr/src/debug/gcc/libstdc++-v3/src/c++17/fast_float/fast_float.h",
line="1815", thread-groups=["i1"]
    }

Change the test to use a more unique name.

Change-Id: I91de781be62d246eb41c73eaa410ebdd12633d1d

Don't explicitly set clone child ptrace options

linux_handle_extended_wait calls target_post_attach if we're handling
a PTRACE_EVENT_CLONE, and libthread_db.so isn't active.
target_post_attach just calls linux_init_ptrace_procfs to set the
lwp's ptrace options.  However, this is completely unnecessary,
because, as man ptrace [1] says, options are inherited:

  "Flags are inherited by new tracees created and "auto-attached" via
   active PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, or PTRACE_O_TRACECLONE
   options."

This removes the unnecessary call.

[1] - https://man7.org/linux/man-pages/man2/ptrace.2.html

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

sim: .gdbinit: generate for all arch subdirs

This was being skipped for ports that had a recursive configure,
but we want it for them too.

sim: build: add a proper var for enabled arches

The install code was using $SUBDIRS to track all enabled arches.  This
works, but isn't great if we want to add a subdir that isn't an arch
port, or as we merge the subdirs into the top-level.  Create a new var
explicitly to track the list of enabled arches instead.

configure: require libzstd >= 1.4.0

gas uses ZSTD_compressStream2 which is only available with libzstd >=
1.4.0, leading to build errors when an older version is installed.

This patch updates the check libzstd presence to check its version is
>= 1.4.0. However, since gas seems to be the only component requiring
such a recent version this may imply that we disable ZSTD support for
all components although some would still benefit from an older
version.

I ran 'autoreconf -f' in all directories containing a configure.ac
file, using vanilla autoconf-2.69 and automake-1.15.1. I noticed
several errors from autoheader in readline, as well as warnings in
intl, but they are unrelated to this patch.

This should fix some of the buildbots.

OK for trunk?

Thanks,

Christophe

ld/testsuite: skip tests related to -shared when disabled

Call the helper function "check_shared_lib_support" to ensure -shared
is enabled before launching ld-shared, ld-elfweak and ld-elfvers.
This allows to catch custom targets explicitly disabling it.

ld/ChangeLog:

* testsuite/ld-elfvers/vers.exp: Call check_shared_lib_support.
* testsuite/ld-elfweak/elfweak.exp: Likewise.
* testsuite/ld-shared/shared.exp: Likewise.

RISC-V: Remove RV32EF conflict

Despite that the RISC-V ISA Manual version 2.2 prohibited "RV32EF", later
versions beginning with the version 20190608-Base-Ratified removed this
restriction.  Because the 'E' extension is still a draft, the author chose
to *just* remove the conflict (not checking the ISA version).

Note that, because RV32E is only used with a soft-float calling convention,
there's no valid official ABI for RV32EF.  It means, even if we can assemble
a program with -march=rv32ef -mabi=ilp32e, floating-point registers are kept
in an unmanaged state (outside ABI management).

The purpose of this commit is to suppress unnecessary errors while parsing
an ISA string and/or disassembling, not to allow hard-float with RVE.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_parse_check_conflicts): Accept RV32EF
because only older specifications disallowed it.

gas/ChangeLog:

* testsuite/gas/riscv/march-fail-rv32ef.d: Remove as not directly
prohibited.
* testsuite/gas/riscv/march-fail-rv32ef.l: Likewise.

Automatic date update in version.in

sim: build: respect AM_MAKEFLAGS when entering subdirs

This doesn't matter right now, but it will as we add more flags to
the recursive make step to pass state down.

sim: build: stop passing down SIM_PRIMARY_TARGET

This was needed when the install step was run in subdirs, but now
that we process that entirely in the top-level, we don't need to
pass this down, so drop it.

Automatic date update in version.in

Deprecate MI version 1

MI version 1 is long since obsolete.  Rather than remove it
immediately (though I did send a patch for that), instead let's
deprecate it in GDB 13 and then remove it for GDB 14.

This version of the patch incorporates Simon's warning change, and
Luis' recommendation to mention the gdb versions here.

sim: fix readline linkage

Now that we link programs in the top dir instead of the arch subdir,
update the readline library path to be relative to the top dir.

sim: use libtool to install programs

Now that we use libtool to link, we have to use it to install instead
of keeping the manual logic so we don't install wrapper shell scripts.

sim: bfin: move linux-fixed-code.h to top-level

sim: run: move linking into top-level

Automake will run each subdir individually before moving on to the next
one.  This means that the linking phase, a single threaded process, will
not run in parallel with anything else.  When we have to link ~32 ports,
that's 32 link steps that don't take advantage of parallel systems.  On
my really old 4-core system, this cuts a multi-target build from ~60 sec
to ~30 sec.  We eventually want to move all compile+link steps to this
common dir anyways, so might as well move linking now for a nice speedup.

We use noinst_PROGRAMS instead of bin_PROGRAMS because we're taking care
of the install ourselves rather than letting automake process it.

sim: build: add uninstall support

This never worked before, but adding it to the common top-level dir
is pretty easy to do now that we're unified.

sim: build: move install steps to the top-level

We still have to maintain custom install rules due to how we rename
arch-specific files with an arch prefix in their name, but we can at
least unify the logic in the common dir.

sim: cris: move rvdummy linking to top-level

This is only used by `make check`, so we can move it out of the
default build too.

sim: build: add SIM_HW_CFLAGS to top-level build too

This matches what we do with targets already.

sim: drop unused SIM_HARDWARE variable

This hasn't been used since the refactor way back in commit
f872d0d643968c1101bb8c07b252edd54f626da2 ("Only enable H/W
on some mips targets."), so punt it.

sim: adjust sim_hw options style

We use uppercase for other variables, and are already turning it to
uppercase in the arch-subdir.mk, so convert it in the configure step.

sim: ppc: drop unused /dev/zero logic

Nothing in the tree checks this option, or has checked for decades.
The pre-cvs-import ChangeLog suggests this was added & removed back
then, but can't be sure as that history doesn't exist in the VCS.

sim: ppc: delete unused host bitsize settings

Nothing checks this define anywhere, so drop all the logic.  We don't
want this to be a configure option in the first place as all such usage
should be automatic & following proper types.

sim: ppc: inline the sim-packages option

This has only ever had a single option that's enabled by default.
The objects it adds are pretty small and don't add overhead at
runtime if it isn't used, so just enable it all the time to make
the build code simpler.

Automatic date update in version.in

binutils: Run PR binutils/26160 test

Update expected PR binutils/26160 test output for readelf out change
and run PR binutils/26160 test.

PR binutils/26160
* testsuite/binutils-all/pr26160.r: Updated.
* testsuite/binutils-all/readelf.exp: Run PR binutils/26160 test.

[testsuite] gdb.base/dlmopen: Fix test name and use gdb_attach

One test name in gdb.base/dlmopen.exp changes from run to run
since it includes a process id:

    PASS: gdb.base/dlmopen.exp: attach 3442682

This is not convenient do diff gdb.sum files to compare test runs.

Fix by using gdb_attach helper function to handle attaching to the
process as it produce a constant test name.

While at it also check gdb_attach's return value to only run the
rest of the test if the attach was successful.

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

PowerPC update comments for the MMA instruction name changes.

The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*,
pmxvi8ger4*, and pmxvi16ger2* instructions were officially changed to
pmdmxbf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*,
pmdmxvi16ger* respectively.  The old mnemonics are still supported by the
assembler as extended mnemonics.  The disassembler generates the new
mnemonics.  The name changes occurred in commit:

  commit bb98553cad4e017f1851153fa5de91f2cee98fb2
  Author: Peter Bergner <bergner@linux.ibm.com>
  Date:   Sat Oct 8 16:19:51 2022 -0500

    PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions

    gas/
            * config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
            * testsuite/gas/ppc/rfc02658.s: New test.
            * testsuite/gas/ppc/rfc02658.d: Likewise.
            * testsuite/gas/ppc/ppc.exp: Run it.

    opcodes/
            * ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New.
            (powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp,
            dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2,
            dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn,
            dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4,
            pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np,
            pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn,
            pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn.

This patch updates the comments in the various gdb files to reflect the
name changes.  There are no functional changes made by this patch.

The older instruction names are still used in the test
gdb.reverse/ppc_record_test_isa_3_1.exp for backwards compatibility.

Patch has been tested on Power 10 with no regressions.

PowerPC fix for the gdb.arch/powerpc-power10.exp test.

The mnemonics for the pmxvf16ger*, pmxvf32ger*,pmxvf64ger*, pmxvi4ger8*,
pmxvi8ger4*, pmxvi16ger2* instructions were officially changed to
pmdmxvf16ger*, pmdmxvf32ger*, pmdmxvf64ger*, pmdmxvi4ger8*, pmdmxvi8ger4*,
pmdmxvi16ger* respectively.  The old mnemonics are still supported by the
assembler as extended mnemonics.  The disassembler generates the new
mnemonics.  The name changes occurred in commit:

  commit bb98553cad4e017f1851153fa5de91f2cee98fb2
  Author: Peter Bergner <bergner@linux.ibm.com>
  Date:   Sat Oct 8 16:19:51 2022 -0500

    PowerPC: Add support for RFC02658 - MMA+ Outer-Product Instructions

    gas/
            * config/tc-ppc.c (md_assemble): Only check for prefix opcodes.
            * testsuite/gas/ppc/rfc02658.s: New test.
            * testsuite/gas/ppc/rfc02658.d: Likewise.
            * testsuite/gas/ppc/ppc.exp: Run it.

    opcodes/
            * ppc-opc.c (XMSK8, P_GERX4_MASK, P_GERX2_MASK, XX3GERX_MASK): New.
            (powerpc_opcodes): Add dmxvi8gerx4pp, dmxvi8gerx4, dmxvf16gerx2pp,
            dmxvf16gerx2, dmxvbf16gerx2pp, dmxvf16gerx2np, dmxvbf16gerx2,
            dmxvi8gerx4spp, dmxvbf16gerx2np, dmxvf16gerx2pn, dmxvbf16gerx2pn,
            dmxvf16gerx2nn, dmxvbf16gerx2nn, pmdmxvi8gerx4pp, pmdmxvi8gerx4,
            pmdmxvf16gerx2pp, pmdmxvf16gerx2, pmdmxvbf16gerx2pp, pmdmxvf16gerx2np,
            pmdmxvbf16gerx2, pmdmxvi8gerx4spp, pmdmxvbf16gerx2np, pmdmxvf16gerx2pn,
            pmdmxvbf16gerx2pn, pmdmxvf16gerx2nn, pmdmxvbf16gerx2nn.

The above commit results in about 224 failures on Power 10 since the
disassembled names do not match the expected names in the test.  This
patch updates the expected names in the test to match the values produced
by the disassembler.

This patch updates file gdb.arch/powerpc-power10.exp with the new expected
values to the instructions.  The comment giving the name of the instruction
for each binary value in the file gdb.arch/powerpc-power10.c is updated
with the new name.   There are no functional changes in file
gdb.arch/powerpc-power10.c.

Powerpc fix for gdb.base/unwind-on-each-insn.exp

The test disassembles function foo and searches for the line
"End of assembler dump" to determing the last address in the function.  The
assumption is the last instruction will be given right before the line
"End of assembler dump".  This assumption fails on PowerPC.

The PowerPC disassembly of the function foo looks like:
 Dump of assembler code for function foo:
#  => 0x00000000100006dc <+0>:     std     r31,-8(r1)
#     0x00000000100006e0 <+4>:     stdu    r1,-48(r1)
#     0x00000000100006e4 <+8>:     mr      r31,r1
#     0x00000000100006e8 <+12>:    nop
#     0x00000000100006ec <+16>:    addi    r1,r31,48
#     0x00000000100006f0 <+20>:    ld      r31,-8(r1)
#     0x00000000100006f4 <+24>:    blr
#     0x00000000100006f8 <+28>:    .long 0x0
#     0x00000000100006fc <+32>:    .long 0x0
#     0x0000000010000700 <+36>:    .long 0x1000180
#     End of assembler dump.

The blr instruction is the last instruction in function foo.  The lines
with .long following the blr instruction need to be ignored.

This patch adds a new condition to the gdb_test_multiple "disassemble foo"
test to ignore the lines with the .long.

The patch has been tested on PowerPC and Intel X86-64.

x86: adjust recently introduced testcases

The issue addressed by 2c02c72c62d2 ("re: Support Intel AMX-FP16") has
been introduced once again in a number of new tests.

Update release documentation with regard to uploading gprofng docs

gdb/testsuite: add KFAILs to gdb.reverse/step-reverse.exp

Recent changes to gdb.reverse/step-reverse.exp revealed the latent bug
PR record/29745, where we can't skip one funcion forward if we're using
native-gdbserver. This commit just adds kfails to the test.

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

opcodes/arm: silence compiler warning about uninitialized variable use

After this commit:

  commit 6576bffe6cbbb53c5756b2fccd2593ba69b74cdf
  Date:   Thu Jul 7 13:43:45 2022 +0100

      opcodes/arm: add disassembler styling for arm

Some people were seeing their builds failing with complaints about a
possible uninitialized variable usage.  I previously fixed an instance
of this issue in this commit:

  commit 2df82cd4b459fbc32120e0ad1ce19e26349506fe
  Date:   Tue Nov 1 10:36:59 2022 +0000

      opcodes/arm: silence compiler warning about uninitialized variable use

which did fix the build problems that the sourceware buildbot was
hitting, however, an additional instance of the same problem was
brought to my attention, and that is fixed in this commit.

Where commit 2df82cd4b4 fixed the uninitialized variable problem in
print_mve_unpredictable, this commit fixes the same problem in
print_mve_undefined.

As with the previous commit, I don't believe we could really ever get
an uninitialized variable usage, based on the current usage of the
function, so I have just initialized the reason variable to "??".

sim: rx: drop unused $arch setting

This is only needed for CGEN ports which RX isn't, so drop it.

sim: build: remove various obsolete generation dep variables

These manual settings were necessary when we weren't doing automatic
header dependency tracking.  That was changed a while ago, and we use
automake now to do it all for us.  As a result, many of these vars
aren't even referenced anymore.

Further, some of the source file generation (e.g. .c files, or igen,
or cgen outputs) were moved to the common automake build, and it takes
care of dependency tracking for us with the object files.

sim: don't hardcode -ldl for SDL support

Since we use AC_SEARCH_LIBS to find dlopen, we don't need to hardcode
-ldl when using SDL ourselves.

Support Intel AVX-NE-CONVERT

gas/ChangeLog:

* NEWS: Support Intel AVX-NE-CONVERT.
* config/tc-i386.c: Add avx_ne_convert.
* doc/c-i386.texi: Document .avx_ne_convert.
* testsuite/gas/i386/i386.exp: Run AVX NE CONVERT tests.
* testsuite/gas/i386/avx-ne-convert-intel.d: New test.
* testsuite/gas/i386/avx-ne-convert.d: Ditto.
* testsuite/gas/i386/avx-ne-convert.s: Ditto.
* testsuite/gas/i386/x86-64-avx-ne-convert-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx-ne-convert.d: Ditto.
* testsuite/gas/i386/x86-64-avx-ne-convert.s: Ditto.

opcodes/ChangeLog:

* i386-dis.c (Mw): New.
(PREFIX_VEX_0F3872): Ditto.
(PREFIX_VEX_0F38B0_W_0): Ditto.
(PREFIX_VEX_0F38B1_W_0): Ditto.
(VEX_W_0F3872_P_1): Ditto.
(VEX_W_0F38B0): Ditto.
(VEX_W_0F38B1): Ditto.
(prefix_table): Add PREFIX_VEX_0F3872, PREFIX_VEX_0F38B0_W_0,
PREFIX_VEX_0F38B1_W_0.
(vex_w_table): Add VEX_W_0F3872_P_1, VEX_W_0F38B0, VEX_W_0F38B1.
* i386-gen.c (cpu_flag_init): Add CPU_AVX_NE_CONVERT_FLGAS and
CPU_ANY_AVX_NE_CONVERT_FLAGS.
(cpu_flags): Add CpuAVX_NE_CONVERT.
* i386-init.h: Regenerated.
* i386-opc.h (CpuAVX_NE CONVERT): New.
(i386_cpu_flags): Add cpuavx_ne_convert.
* i386-opc.tbl: Add Intel AVX-NE-CONVERT instructions.
* i386-tbl.h: Regenerated.

i386: Rename <xy> template.

opcodes/
            * i386-opc.tbl: Rename <xy> template for VEX insn with x/y suffix to <Vxy>.
    Rename <xy> for EVEX insn with x/y suffix to <Exy>.

Support multiple .eh_frame sections

This patch is based on MULTIPLE_FRAME_SECTIONS and EH_FRAME_LINKONCE,
it allows backend to enable this feature and use '--gc-sections' simply.

* gas/dw2gencfi.h (TARGET_MULTIPLE_EH_FRAME_SECTIONS): New.
(MULTIPLE_FRAME_SECTIONS): Add TARGET_MULTIPLE_EH_FRAME_SECTIONS.
* gas/dw2gencfi.c (EH_FRAME_LINKONCE): Add TARGET_MULTIPLE_EH_FRAME_SECTIONS.
(is_now_linkonce_segment): Likewise.
(get_cfi_seg): Create relocation info between .eh_frame.* and .text.* section.

* bfd/elf-bfd.h (elf_backend_can_make_multiple_eh_frame): New.
* bfd/elfxx-target.h (elf_backend_can_make_multiple_eh_frame): Likewise.
* bfd/elflink.c (_bfd_elf_default_action_discarded): Add checking for
elf_backend_can_make_multiple_eh_frame.

gas/doc/internals.texi: fix typo

* gas/doc/internals.texi (md_emit_single_noop_insn):
fix '@var missing closing brace'
* gas/doc/internals.texi (Hash tables):
fix '@menu reference to nonexistent node `Hash tables''

sim: drop -lm from SIM_EXTRA_LIBS

We have configure tests for this in the top-level configure script
to link this when necessary, so we don't need to explicitly list it
for specific ports.

sim: build: change AC_CHECK_LIB to AC_SEARCH_LIBS

With more C libraries moving functions entirely into the main -lc,
change the AC_CHECK_LIB calls to AC_SEARCH_LIBS so we look in there
first and avoid extra linkage when possible.

sim: build: drop duplicate $(LIBS) usage

COMMON_LIBS is set to $(LIBS), and CONFIG_LIBS is set to that plus
@LIBS@.  This leds to the values being used twice.  Inline the
CONFIG_LIBS variable without @LIBS@ since it's used only once.

sim: build: switch to bfd & opcodes libtool linker scripts

Now that we use libtool to link, we don't need to duplicate all the
libs that bfd itself uses.  This simplifies the configure & Makefile.

sim: build: switch to libtool for linking

The top-level already sets up a libtool script for the host, so use
that when linking rather than invoking CC directly.  This will also
happen when we (someday) move the building to pure automake.

Automatic date update in version.in

sim: testsuite: fix cris stat3 in diff setups

This test uses the test itself as an input to stating regular files.
This gets funky though: when we run check in parallel, the output
object dir is the subdir that matches the .exp file.  When we run
with -j1, the output object dir is the sim builddir itself.

The old test would append argv[0] to find the file, while the new
test uses basename on it.  Each method works in only one of the
aforementioned build scenarios.  Rather than complicate this any
more, switch to a different file that we know will always exist:
the Makefile.

sim: testsuite: fix cris badarch in multi-target builds

This test assumes that /bin/sh will never be a CRIS ELF by way of
assuming that the current bfd cannot load it (since a basic cris
cross-compiler only understands CRIS ELFs).  In a multi-target
build though, bfd understands just about every ELF out there, so
we're able to read the /bin/sh format before failing at a diff
point in the cris code.

Let's switch to using / instead since it'll fail for a similar
reason (at least similar enough for what this test is testing).

sim: cleanup unused SIM_EXTRA_CFLAGS

We want to eventually delete this, so at least drop the empty ones.

sim: m32c/rx: drop useless $(ENDLIST)

This is used to allow for dangling \ in object lists, but these are the
only ports that do it, and it isn't really necessary.  Punt it to keep
the various makefiles harmonized.

sim: mips: simplify fpu configure logic

The configure code always defaults to HARD_FLOATING_POINT, so inline
that value and drop redundant target checks as a result.

sim: erc32: link sis to run program

The erc32 sim does a lot itself, including handling of the CLI.  It
used to provide a run-compatible interface in the pre-nrun days, but
it was dropped when the old run interface was punted.  Since the old
commit 465fb143c87076b6416a8d0d5dd79bb016060fe3 ("sim: make nrun the
default run program"), the erc32 run & sis programs have been the
same, and erc32 hasn't provide a real run-compatible interface.

Simplify this by linking the two programs via ln/cp instead of running
the linking phase twice to produce the same result.  If/when we fix up
the erc32 port to have a proper run interface, it should be easy to
split these back apart into real programs.

Note: the interf.o reference in here is a bit of a misdirect.  Since
that object is placed into libsim.a, it's never been linked into the
programs since the linker ignores objects that aren't referenced, and
only gdb uses those symbols.

V850 Linker: do not complain about RWX segments.

PR 29748
* configure.tgt (ac_default_ld_warn_rwx_segments): Set to 0 for
the V850.

sim: v850: switch to standard (high-level) trace defines

The v850 port uses -DDEBUG to control whether to enable internal tracing.
We already have such options via the common trace framework, and those
can be controlled at build time via configure flags (which the v850 code
currently cannot).  So switch it over to WITH_TRACE_ANY_P to simplify the
v850 build code even if it doesn't (yet) respect any other trace options.

sim: ppc: include copyright & license in --version

This makes it match the other sim run programs and GNU tools.

sim: update --version copyright year

Probably should have done this 11 months ago ...

sim: ppc: drop use of DATE & TIME

No other tool does this, sim or otherwise, and it makes the ppc build
non-reproducible.  Drop it to simplify & make reproducible.

gdb: Fix issue with Clang CLI macros

Clang up to version 15 (current) adds macros that were defined in the
command line or by "other means", according to the Dwarf specification,
after the last DW_MACRO_end_file, instead of before the first
DW_MACRO_start_file, as the specification dictates.  When GDB reads the
macros after the last file is closed, the macros never end up "in scope"
and so we can't print them.  This has been submitted as a bug to Clang
developers (https://github.com/llvm/llvm-project/issues/54506), and PR
macros/29034 was opened for GDB to keep track of this.

Seeing as there is no expected date for it to be fixed, add a workaround
for all current versions of Clang.  The workaround detects when
the main file would be closed and if the producer is Clang, and turns
that operation into a noop, so we keep a reference to the current_file
as those macros are read.

A test case was added to confirm the functionality, and the KFAIL for
running gdb.base/macro-source-path when using clang.

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

AVR Linker: Allow the start of the data region to be specified on the linker command line.  [Fix PR number in ChangeLog entry]

PR 29741
* scripttempl/avr.sc (__DATA_REGION_ORIGIN__): Define.  If a value
has not been provided on the command line then use DATA_ORIGIN.
(MEMORY): Use __DATA_REGION_ORIGIN__ as the start of the data region.

AVR Linker: Allow the start of the data region to specified on the command line.

PR 29471
* scripttempl/avr.sc (__DATA_REGION_ORIGIN__): Define.  If a value
has not been provided on the command line then use DATA_ORIGIN.
(MEMORY): Use __DATA_REGION_ORIGIN__ as the start of the data region.

sim: move common flags to default AM_CPPFLAGS

Since all host files we compile use these settings, move them out of
libcommon.a and into the default AM_CPPFLAGS.  This has the effect of
dropping the custom per-target automake rules.  Currently it saves us
~150 lines, but since it's about ~8 lines per object, the overhead
will increase quite a bit as we merge more files into a single build.

This also changes the object output names, so we have to tweak the
rules that were pulling in the common objects when linking.

sim: merge gnulib logic into the top-level

We aren't using this just yet, but we will, so make it available to
building of common sim files.

sim: common: remove unused include paths

A bunch of these paths don't include any headers, and most likely
never will, so there's no real need to keep them.  This will let
us harmonize paths with the top-level Makefile more easily, which
will in turn make it easier to move more compile steps there.

Automatic date update in version.in

arm: PR 29739 Fix typo where ';' should not have been replaced with '@'

';' does not always indicate the start of a comment, and commit
8cb6e17571f3fb66ccd4fa19f881602542cd06fc incorrectly replaced 3
instances of ';' with '@' in expected diagnostics, leading to tests
failures.

This patch restores the original ';' as needed in these testcases.

Fixes bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29739

sim: split CPPFLAGS between build & host

In order to merge more common/ files into the top-level, we need to
add more host flags to CPPFLAGS, and that conflicts with our current
use with build-time tools.  So split them apart like we do with all
other build flags to avoid the issue.

sim: h8300: switch to cpu for state

Rather than rely on pulling out the first cpu from the sim state
for cpu state, pass down the active cpu that's already available.

sim: common: change sim_{fetch,store}_register helpers to use void* buffers

When reading/writing arbitrary data to the system's memory, the unsigned
char pointer type doesn't make that much sense.  Switch it to void so we
align a bit with standard C library read/write functions, and to avoid
having to sprinkle casts everywhere.

Fix Cygwin build after 20489cca

Update code under __CYGWIN__ which accesses inferior process information
which is now stored in windows_process_info rather than globals.

Fix Cygwin build after bcb9251f

Absent _UNICODE being defined (which gdb's Makefile doesn't do),
windows.h will always define STARTUPINFO is as STARTUPINFOA, so this
cast isn't correct when create_process expects a STARTUPINFOW
parameter (i.e. in a Cygwin build).

Instead write this as &info_ex.StartupInfo (which is always of the
correct type).

x86: drop bogus Tbyte

Prior to commit 1cb0ab18ad24 ("x86/Intel: restrict suffix derivation")
the Tbyte modifier on the FLDT and FSTPT templates was pointless, as
No_ldSuf would have prevented it being accepted. Due to the special
nature of LONG_DOUBLE_MNEM_SUFFIX said commit, however, has led to these
insns being accepted in Intel syntax mode even when "tbyte ptr" was
present. Restore original behavior by dropping Tbyte there. (Note that
these insns in principle should by marked AT&T syntax only, but since
they haven't been so far we probably shouldn't change that.)

x86: simplify expressions in update_imm()

Comparing the sum of the relevant .imm<N> fields against a constant imo
makes more obvious what is actually meant. It allows dropping of two
static variables, with a 3rd drop requiring two more minor adjustments
elsewhere, utilizing that "i" is zeroed first thing in md_assemble().
This also increases the chances of the compiler doing the calculations
all in registers.

RISC-V: Fixed the missing $x+arch when adding odd paddings for alignment.

Consider the case,

.option arch, rv32i
.option norelax
.option arch, +c
.byte   1
.align  2
addi    a0, zero, 1

Assembler adds $d for the odd .byte, and then adds $x+arch for the
alignment.  Since norelax, riscv_add_odd_padding_symbol will add the
$d and $x for the odd alignment, but accidently remove the $x+arch because
it has the same address as $d.  Therefore, we will get the unexpected result
before applying this patch,

.byte   1            # $d
.align  2            # odd alignment, $xrv32ic replaced by $d + $x

After this patch, the expected result should be,

.byte   1            # $d
.align  2            # odd alignment, $xrv32ic replaced by $d + $xrv32ic

gas/
    * config/tc-riscv.c (make_mapping_symbol): If we are adding mapping symbol
    for odd alignment, then we probably will remove the $x+arch by accidently
    when it has the same address of $d.  Try to add the removed $x+arch back
    after the $d rather than just $x.
    (riscv_mapping_state): Updated since parameters of make_mapping_symbol are
    changed.
    (riscv_add_odd_padding_symbol): Likewise.
    (riscv_remove_mapping_symbol): Removed and moved the code into the
    riscv_check_mapping_symbols.
    (riscv_check_mapping_symbols): Updated.
    * testsuite/gas/riscv/mapping-dis.d: Updated and added new testcase.
    * testsuite/gas/riscv/mapping-symbols.d: Likewise.
    * testsuite/gas/riscv/mapping.s: Likewise.

Support Intel MSRLIST

gas/ChangeLog:

* NEWS: Support Intel MSRLIST.
* config/tc-i386.c: Add msrlist.
* doc/c-i386.texi: Document .msrlist.
* testsuite/gas/i386/i386.exp: Add MSRLIST tests.
* testsuite/gas/i386/msrlist-inval.l: New test.
* testsuite/gas/i386/msrlist-inval.s: Ditto.
* testsuite/gas/i386/x86-64-msrlist-intel.d: Ditto.
* testsuite/gas/i386/x86-64-msrlist.d: Ditto.
* testsuite/gas/i386/x86-64-msrlist.s: Ditto.

opcodes/ChangeLog:

* i386-dis.c (X86_64_0F01_REG_0_MOD_3_RM_6_P_1): New.
(X86_64_0F01_REG_0_MOD_3_RM_6_P_3): Ditto.
(prefix_table): New entry for msrlist.
(x86_64_table): Add X86_64_0F01_REG_0_MOD_3_RM_6_P_1
and X86_64_0F01_REG_0_MOD_3_RM_6_P_3.
* i386-gen.c (cpu_flag_init): Add CPU_MSRLIST_FLAGS
and CPU_ANY_MSRLIST_FLAGS.
* i386-init.h: Regenerated.
* i386-opc.h (CpuMSRLIST): New.
(i386_cpu_flags): Add cpumsrlist.
* i386-opc.tbl: Add MSRLIST instructions.
* i386-tbl.h: Regenerated.

Support Intel WRMSRNS

gas/ChangeLog:

        * NEWS: Support Intel WRMSRNS.
        * config/tc-i386.c: Add wrmsrns.
        * doc/c-i386.texi: Document .wrmsrns.
        * testsuite/gas/i386/i386.exp: Add WRMSRNS tests.
        * testsuite/gas/i386/wrmsrns-intel.d: New test.
        * testsuite/gas/i386/wrmsrns.d: Ditto.
        * testsuite/gas/i386/wrmsrns.s: Ditto.
        * testsuite/gas/i386/x86-64-wrmsrns-intel.d: Ditto.
        * testsuite/gas/i386/x86-64-wrmsrns.d: Ditto.

opcodes/ChangeLog:

* i386-dis.c (PREFIX_0F01_REG_0_MOD_3_RM_6): New.
(prefix_table): Add PREFIX_0F01_REG_0_MOD_3_RM_6.
(rm_table): New entry for wrmsrns.
* i386-gen.c (cpu_flag_init): Add CPU_WRMSRNS_FLAGS
and CPU_ANY_WRMSRNS_FLAGS.
(cpu_flags): Add CpuWRMSRNS.
        * i386-init.h: Regenerated.
        * i386-opc.h (CpuWRMSRNS): New.
(i386_cpu_flags): Add cpuwrmsrns.
        * i386-opc.tbl: Add WRMSRNS instructions.
        * i386-tbl.h: Regenerated.

Add handler for more i386_cpu_flags

gas/ChangeLog:

* config/tc-i386.c (cpu_flags_all_zero): Add new ARRAY_SIZE handle.
(cpu_flags_equal): Ditto.
(cpu_flags_and): Ditto.
(cpu_flags_or): Ditto.
(cpu_flags_and_not): Ditto.

Support Intel CMPccXADD

gas/ChangeLog:

* NEWS: Support Intel CMPccXADD.
* config/tc-i386.c: Add cmpccxadd.
(build_modrm_byte): Add operations for Vex.VVVV reg
on operand 0 while have memory operand.
* doc/c-i386.texi: Document .cmpccxadd.
* testsuite/gas/i386/i386.exp: Run CMPccXADD tests.
* testsuite/gas/i386/cmpccxadd-inval.s: New test.
* testsuite/gas/i386/cmpccxadd-inval.l: Ditto.
* testsuite/gas/i386/x86-64-cmpccxadd-intel.d: Ditto.
* testsuite/gas/i386/x86-64-cmpccxadd.s: Ditto.
* testsuite/gas/i386/x86-64-cmpccxadd.d: Ditto.

opcodes/ChangeLog:

* i386-dis.c (Mdq): New.
(X86_64_VEX_0F38E0): Ditto.
(X86_64_VEX_0F38E1): Ditto.
(X86_64_VEX_0F38E2): Ditto.
(X86_64_VEX_0F38E3): Ditto.
(X86_64_VEX_0F38E4): Ditto.
(X86_64_VEX_0F38E5): Ditto.
(X86_64_VEX_0F38E6): Ditto.
(X86_64_VEX_0F38E7): Ditto.
(X86_64_VEX_0F38E8): Ditto.
(X86_64_VEX_0F38E9): Ditto.
(X86_64_VEX_0F38EA): Ditto.
(X86_64_VEX_0F38EB): Ditto.
(X86_64_VEX_0F38EC): Ditto.
(X86_64_VEX_0F38ED): Ditto.
(X86_64_VEX_0F38EE): Ditto.
(X86_64_VEX_0F38EF): Ditto.
(x86_64_table): Add X86_64_VEX_0F38E0, X86_64_VEX_0F38E1,
X86_64_VEX_0F38E2, X86_64_VEX_0F38E3, X86_64_VEX_0F38E4,
X86_64_VEX_0F38E5, X86_64_VEX_0F38E6, X86_64_VEX_0F38E7,
X86_64_VEX_0F38E8, X86_64_VEX_0F38E9, X86_64_VEX_0F38EA,
X86_64_VEX_0F38EB, X86_64_VEX_0F38EC, X86_64_VEX_0F38ED,
X86_64_VEX_0F38EE, X86_64_VEX_0F38EF.
* i386-gen.c (cpu_flag_init): Add CPU_CMPCCXADD_FLAGS and
CPU_ANY_CMPCCXADD_FLAGS.
(cpu_flags): Add CpuCMPCCXADD.
* i386-init.h: Regenerated.
* i386-opc.h (CpuCMPCCXADD): New.
(i386_cpu_flags): Add cpucmpccxadd. Comment unused for it is actually 0.
* i386-opc.tbl: Add Intel CMPccXADD instructions.
* i386-tbl.h: Regenerated.

Support Intel AVX-VNNI-INT8

gas/
        * NEWS: Support Intel AVX-VNNI-INT8.
* config/tc-i386.c: Add avx_vnni_int8.
* doc/c-i386.texi: Document avx_vnni_int8.
* testsuite/gas/i386/avx-vnni-int8-intel.d: New file.
* testsuite/gas/i386/avx-vnni-int8.d: Likewise.
* testsuite/gas/i386/avx-vnni-int8.s: Likewise.
* testsuite/gas/i386/x86-64-avx-vnni-int8-intel.d: Likewise.
* testsuite/gas/i386/x86-64-avx-vnni-int8.d: Likewise.
* testsuite/gas/i386/x86-64-avx-vnni-int8.s: Likewise.
* testsuite/gas/i386/i386.exp: Run AVX VNNI INT8 tests.

opcodes/
* i386-dis.c: (PREFIX_VEX_0F3850) New.
(PREFIX_VEX_0F3851): Likewise.
(VEX_W_0F3850_P_0): Likewise.
(VEX_W_0F3850_P_1): Likewise.
(VEX_W_0F3850_P_2): Likewise.
(VEX_W_0F3850_P_3): Likewise.
(VEX_W_0F3851_P_0): Likewise.
(VEX_W_0F3851_P_1): Likewise.
(VEX_W_0F3851_P_2): Likewise.
(VEX_W_0F3851_P_3): Likewise.
(VEX_W_0F3850): Delete.
(VEX_W_0F3851): Likewise.
(prefix_table): Add PREFIX_VEX_0F3850 and PREFIX_VEX_0F3851.
(vex_table): Add PREFIX_VEX_0F3850 and PREFIX_VEX_0F3851,
delete VEX_W_0F3850 and VEX_W_0F3851.
(vex_w_table): Add VEX_W_0F3850_P_0, VEX_W_0F3850_P_1, VEX_W_0F3850_P_2
VEX_W_0F3850_P_3, VEX_W_0F3851_P_0, VEX_W_0F3851_P_1, VEX_W_0F3851_P_2
and VEX_W_0F3851_P_3, delete VEX_W_0F3850 and VEX_W_0F3851.
* i386-gen.c: (cpu_flag_init): Add CPU_AVX_VNNI_INT8_FLAGS
and CPU_ANY_AVX_VNNI_INT8_FLAGS.
(cpu_flags): Add CpuAVX_VNNI_INT8.
* i386-opc.h (CpuAVX_VNNI_INT8): New.
* i386-opc.tbl: Add Intel AVX_VNNI_INT8 instructions.
* i386-init.h: Regenerated.
* i386-tbl.h: Likewise.

Support Intel AVX-IFMA

x86: Support Intel AVX-IFMA

Intel AVX IFMA instructions are marked with CpuVEX_PREFIX, which is
cleared by default.  Without {vex} pseudo prefix, Intel IFMA instructions
are encoded with EVEX prefix.  {vex} pseudo prefix will turn on VEX
encoding for Intel IFMA instructions.

gas/

* NEWS: Support Intel AVX-IFMA.
* config/tc-i386.c (cpu_arch): Add avx_ifma.
* doc/c-i386.texi: Document .avx_ifma.
* testsuite/gas/i386/avx-ifma.d: New file.
* testsuite/gas/i386/avx-ifma-intel.d: Likewise.
* testsuite/gas/i386/avx-ifma.s: Likewise.
* testsuite/gas/i386/x86-64-avx-ifma.d: Likewise.
* testsuite/gas/i386/x86-64-avx-ifma-intel.d: Likewise.
* testsuite/gas/i386/x86-64-avx-ifma.s: Likewise.
* testsuite/gas/i386/i386.exp: Run AVX IFMA tests.

opcodes/

* i386-dis.c (PREFIX_VEX_0F38B4): New.
(PREFIX_VEX_0F38B5): Likewise.
(VEX_W_0F38B4_P_2): Likewise.
(VEX_W_0F38B5_P_2): Likewise.
(prefix_table): Add PREFIX_VEX_0F38B4 and PREFIX_VEX_0F38B5.
(vex_table): Add VEX_W_0F38B4_P_2 and VEX_W_0F38B5_P_2.
* i386-dis-evex.h: Fold AVX512IFMA entries to AVX-IFMA.
* i386-gen.c (cpu_flag_init): Clear the CpuAVX_IFMA bit in
CPU_UNKNOWN_FLAGS. Add CPU_AVX_IFMA_FLGAS and
CPU_ANY_AVX_IFMA_FLAGS. Add CpuAVX_IFMA to CPU_AVX2_FLAGS.
(cpu_flags): Add CpuAVX_IFMA.
* i386-opc.h (CpuAVX_IFMA): New.
(i386_cpu_flags): Add cpuavx_ifma.
* i386-opc.tbl: Add Intel AVX IFMA instructions.
* i386-init.h: Regenerated.
* i386-tbl.h: Likewise.

Co-authored-by: Haochen Jiang <haochen.jiang@intel.com>

Automatic date update in version.in

opcodes/arm: don't pass non-string literal to printf like function

The earlier commit:

  commit 6576bffe6cbbb53c5756b2fccd2593ba69b74cdf
  Date:   Thu Jul 7 13:43:45 2022 +0100

      opcodes/arm: add disassembler styling for arm

introduced two places where a register name was passed as the format
string to the disassembler's fprintf_styled_func callback.  This will
cause a warning from some compilers, like this:

  ../../binutils-gdb/opcodes/arm-dis.c: In function ‘print_mve_vld_str_addr’:
  ../../binutils-gdb/opcodes/arm-dis.c:6005:3: error: format not a string literal and no format arguments [-Werror=format-security]
   6005 |   func (stream, dis_style_register, arm_regnames[gpr]);
        |   ^~~~

This commit fixes these by using "%s" as the format string.

opcodes/arm: silence compiler warning about uninitialized variable use

The earlier commit:

  commit 6576bffe6cbbb53c5756b2fccd2593ba69b74cdf
  Date:   Thu Jul 7 13:43:45 2022 +0100

      opcodes/arm: add disassembler styling for arm

was causing a compiler warning about a possible uninitialized variable
usage within opcodes/arm-dis.c.

The problem is in print_mve_unpredictable, and relates to the reason
variable, which is set by a switch table.

Currently the switch table does cover every valid value, though there
is no default case.  The variable switched on is passed in as an
argument to the print_mve_unpredictable function.

Looking at how print_mve_unpredictable is used, there is only one use,
the second argument is the one that is used for the switch table,
looking at how this argument is set, I don't believe it is possible
for this argument to take an invalid value.

So, I think the compiler warning is a false positive.  As such, my
proposed solution is to initialize the reason variable to the string
"??", this will silence the warning, and the "??" string should never
end up being printed.

opcodes/arm: add disassembler styling for arm

This commit adds disassembler styling for the ARM architecture.

The ARM disassembler is driven by several instruction tables,
e.g. cde_opcodes, coprocessor_opcodes, neon_opcodes, etc

The type for elements in each table can vary, but they all have one
thing in common, a 'const char *assembler' field.  This field
contains a string that describes the assembler syntax of the
instruction.

Embedded within that assembler syntax are various escape characters,
prefixed with a '%'.  Here's an example of a very simple instruction
from the arm_opcodes table:

  "pld\t%a"

The '%a' indicates a particular type of operand, the function
print_insn_arm processes the arm_opcodes table, and includes a switch
statement that handles the '%a' operand, and takes care of printing
the correct value for that instruction operand.

It is worth noting that there are many print_* functions, each
function handles a single *_opcodes table, and includes its own switch
statement for operand handling.  As a result, every *_opcodes table
uses a different mapping for the operand escape sequences.  This means
that '%a' might print an address for one *_opcodes table, but in a
different *_opcodes table '%a' might print a register operand.

Notice as well that in our example above, the instruction mnemonic
'pld' is embedded within the assembler string.  Some instructions also
include comments within the assembler string, for example, also from
the arm_opcodes table:

  "nop\t\t\t@ (mov r0, r0)"

here, everything after the '@' is a comment that is displayed at the
end of the instruction disassembly.

The next complexity is that the meaning of some escape sequences is
not necessarily fixed.  Consider these two examples from arm_opcodes:

  "ldrex%c\tr%12-15d, [%16-19R]"
  "setpan\t#%9-9d"

Here, the '%d' escape is used with a bitfield modifier, '%12-15d' in
the first instruction, and '%9-9d' in the second instruction, but,
both of these are the '%d' escape.

However, in the first instruction, the '%d' is used to print a
register number, notice the 'r' immediately before the '%d'.  In the
second instruction the '%d' is used to print an immediate, notice the
'#' just before the '%d'.

We have two problems here, first, the '%d' needs to know if it should
use register style or immediate style, and secondly, the 'r' and '#'
characters also need to be styled appropriately.

The final thing we must consider is that some escape codes result in
more than just a single operand being printed, for example, the '%q'
operand as used in arm_opcodes ends up calling arm_decode_shift, which
can print a register name, a shift type, and a shift amount, this
could end up using register, sub-mnemonic, and immediate styles, as
well as the text style for things like ',' between the different
parts.

I propose a three layer approach to adding styling:

(1) Basic state machine:

    When we start printing an instruction we should maintain the idea
    of a 'base_style'.  Every character from the assembler string will
    be printed using the base_style.

   The base_style will start as mnemonic, as each instruction starts
   with an instruction mnemonic.  When we encounter the first '\t'
   character, the base_style will change to text.  When we encounter
   the first '@' the base_style will change to comment_start.

   This simple state machine ensures that for simple instructions the
   basic parts, except for the operands themselves, will be printed in
   the correct style.

(2) Simple operand styling:

    For operands that only have a single meaning, or which expand to
    multiple parts, all of which have a consistent meaning, then I
    will simply update the operand printing code to print the operand
    with the correct style.  This will cover a large number of the
    operands, and is the most consistent with how styling has been
    added to previous architectures.

(3) New styling syntax in assembler strings:

    For cases like the '%d' that I describe above, I propose adding a
    new extension to the assembler syntax.  This extension will allow
    me to temporarily change the base_style.  Operands like '%d', will
    then print using the base_style rather than using a fixed style.

    Here are the two examples from above that use '%d', updated with
    the new syntax extension:

      "ldrex%c\t%{R:r%12-15d%}, [%16-19R]"
      "setpan\t%{I:#%9-9d%}"

    The syntax has the general form '%{X:....%}' where the 'X'
    character changes to indicate a different style.  In the first
    instruction I use '%{R:...%}' to change base_style to the register
    style, and in the second '%{I:...%}' changes base_style to
    immediate style.

    Notice that the 'r' and '#' characters are included within the new
    style group, this ensures that these characters are printed with
    the correct style rather than as text.

    The function decode_base_style maps from character to style.  I've
    included a character for each style for completeness, though only
    a small number of styles are currently used.

I have updated arm-dis.c to the above scheme, and checked all of the
tests in gas/testsuite/gas/arm/, and the styling looks reasonable.

There are no regressions on the ARM gas/binutils/ld tests that I can
see, so I don't believe I've changed the output layout at all.  There
were two binutils tests for which I needed to force the disassembler
styling off.

I can't guarantee that I've not missed some untested corners of the
disassembler, or that I might have just missed some incorrectly styled
output when reviewing the test results, but I don't believe I've
introduced any changes that could break the disassembler - the worst
should be some aspect is not styled correctly.

opcodes/arm: use '@' consistently for the comment character

Looking at the ARM disassembler output, every comment seems to start
with a ';' character, so I assumed this was the correct character to
start an assembler comment.

I then spotted a couple of places where there was no ';', but instead,
just a '@' character.  I thought that this was a case of a missing
';', and proposed a patch to add the missing ';' characters.

Turns out I was wrong, '@' is actually the ARM assembler comment
character, while ';' is the statement separator.  Thus this:

    nop    ;@ comment

is two statements, the first is the 'nop' instruction, while the
second contains no instructions, just the '@ comment' comment text.

This:

    nop    @ comment

is a single 'nop' instruction followed by a comment.  And finally,
this:

    nop    ; comment

is two statements, the first contains the 'nop' instruction, while the
second contains the instruction 'comment', which obviously isn't
actually an instruction at all.

Why this matters is that, in the next commit, I would like to add
libopcodes syntax styling support for ARM.

The question then is how should the disassembler style the three cases
above?

As '@' is the actual comment start character then clearly the '@' and
anything after it can be styled as a comment.  But what about ';' in
the second example?  Style as text?  Style as a comment?

And the third example is even harder, what about the 'comment' text?
Style as an instruction mnemonic?  Style as text?  Style as a comment?

I think the only sensible answer is to move the disassembler to use
'@' consistently as its comment character, and remove all the uses of
';'.

Then, in the next commit, it's obvious what to do.

There's obviously a *lot* of tests that get updated by this commit,
the only actual code changes are in opcodes/arm-dis.c.

Automatic date update in version.in

Add missing TYPE_CODE_* constants to Python

A user noticed that TYPE_CODE_FIXED_POINT was not exported by the gdb
Python layer.  This patch fixes the bug, and prevents future
occurences of this type of bug.

Remove REPARSE condition to force hardware resource checking when updating watchpoints

Currently the resource checking is done if REPARSE is true.  The hardware
watchpoint resource checking in update_watchpoint needs to be redone on
each call to function update_watchpoints as the value chain may have
changed.  The number of hardware registers needed for a watchpoint can
change if the variable being watched changes.  This situation occurs in
this test when watching variable **global_ptr_ptr.  Initially when the
watch command is issued, only two addresses need to be watched as
**global_ptr_ptr has not yet been initialized.  Once the value of
**global_ptr_ptr is initialized the locations to be tracked increase to
three addresses.  However, update_watchpoints is not called again with
REPARSE set to 1 to force the resource checking to be redone.  When the
test is run on Power 10, an internal gdb error occurs when the PowerPC
routine tries to setup the three hardware watchpoint address since the hw
only has two hardware watchpoint registers.  The error occurs because the
resource checking was not redone in update_watchpoints after
**global_ptr_ptr changed.

The following descibes the situation in detail that occurs on Power 10 with
gdb running on the binary for gdb.base/watchpoint.c.

1 break func4
2 run
3 watch *global_ptr
4 next      execute source code:   buf[0] = 3;
5 next      execute source code:   global_ptr = buf;
6 next      execute source code:   buf[0] = 7;
7 delete 2  (delete watch *global_ptr)
8 watch **global_ptr_ptr
9 next       execute source code:   buf[1] = 5;
10 next      global_ptr_ptr = &global_ptr;
11 next      buf[0] = 9;

In step 8, the the watch **global_ptr_prt command calls update_watchpoint
in breakpoint.c with REPARSE set to 1.  The function update_watchpoint
calls can_use_hardware_watchpoint to see if there are enough
resources available to add the watchpoint since REPARSE is set to 1.  At
this point, **global_ptr_ptr has not been initialized so only two addresses
are watched.  The val_chain contains the address for **global_ptr_ptr and 0
since **global_ptr_ptr has not been initialized.  The update_watchpoint
updates the breakpoint list as follows:

  breakpoint 0
   loc 0: b->address = 0x100009c0
  breakpoint 1
   loc 1: b->address = 0x7ffff7f838a0
  breakpoint 2
   loc 2: b->address = 0x7ffff7b7fc54
  breakpoint 3
   loc 3: b->address = 0x7ffff7a5788c
  breakpoint 4
   loc 4: b->address = 0x0         <-- location pointed to by global_ptr_ptr
   loc 5: b->address = 0x100200b8  <-- global_ptr_ptr watchpoint
  breakpoint 5
   loc 6: b->address = 0x7ffff7b7fc54

In step 10, the next command executes the source code
global_ptr_ptr = &global_ptr.  This changes the set of locations to be
watched for the watchpoint **global_ptr_prt.  The list of addresses for the
breakpoint consist of the address for global_ptr_prt, global_ptr and buf.
The breakpoint list gets updated by update_watchpoint as follows:

  breakpoint 0
   loc 0: b->address = 0x100009c0
  breakpoint 1
   loc 1: b->address = 0x7ffff7f838a0
  breakpoint 2
   loc 2: b->address = 0x7ffff7b7fc54
  breakpoint 3
   loc 3: b->address = 0x7ffff7a5788c
  breakpoint 4
   loc 4: b->address = 0x10020050           buf
   loc 5: b->address = 0x100200b0           watch *global_ptr
   loc 6: b->address = 0x100200b8           watch **global_ptr_ptr
  breakpoint 5
   loc 7: b->address = 0x7ffff7b7fc54
  breakpoint 6

However, the hardware resource checking was not redone because
update_breakpoint was called with REPARSE equal to  0.

Step 11, execute the third next command.  The function
ppc_linux_nat_target::low_prepare_to_resume() attempts a ptrace
call to setup each of the three address for breakpoint 4.  The slot
value returned for the third ptrace call is -1 indicating an error
because there are only two hardware watchpoint registers available on
Power 10.

This patch removes just the statement "if (reparse)" in function
update_watchpoint to force the resources to be rechecked on every call to
the function.  This ensures that any changes to the val_chain resulting
in needing more resources then available will be caught.

The patch has been tested on Power 8, Power 10 and X86-64.  Note the patch
has no effect on Power 9 since hardware watchpoint support is disabled on
that processor.

PowerPC, add support for recording pipe2 system call.

Test gdb.reverse/pipe-reverse.exp fails on Power 10 running the fedora 36
distro.  The gdb record error message is:

  Process record and replay target doesn't support syscall number 317.

System call 317 on PowerPC maps to the pipe2 system call.

This patch adds support for the missing pipe2 system call for PowerPC.

Patch fixes the test failure in gdb.reverse/pipe-reverse.exp.

The patch has been tested on Power 10 with no regression failures.

x86: minor improvements to optimize_imm() (part III)

Earlier tidying still missed an opportunity: There's no need for the
"anyimm" static variable. Instead of using it in the loop to mask
"allowed" (which is necessary to satisfy operand_type_or()'s assertions)
simply use "mask", requiring it to be calculated first. That way the
post-loop masking by "mask" ahead of the operand_type_all_zero() can be
dropped.

sim: reg: constify store helper

These functions only read from memory, so mark the pointer as const.

sim: constify various integer readers

These functions only read from memory, so mark the pointer as const.

sim: cgen: constify GETT helpers

These functions only read from memory, so mark the pointer as const.

sim: common: change sim_read & sim_write to use void* buffers

When reading/writing arbitrary data to the system's memory, the unsigned
char pointer type doesn't make that much sense.  Switch it to void so we
align a bit with standard C library read/write functions, and to avoid
having to sprinkle casts everywhere.

x86: Silence GCC 12 warning on tc-i386.c

Silence GCC 12 warning on tc-i386.c:

gas/config/tc-i386.c: In function ‘md_assemble’:
gas/config/tc-i386.c:5039:16: error: too many arguments for format [-Werror=format-extra-args]
 5039 |     as_warn (_("only support RIP-relative address"), i.tm.name);

* config/tc-i386.c (md_assemble): Print mnemonic in RIP-relative
warning.
* estsuite/gas/i386/x86-64-prefetchi-warn.l: Updated.

Use enum for gdbarch's call_dummy_location

This changes gdbarch to use an enum for call_dummy_location, providing
a little more type safety.

Inline initialization of gdbarch members

This changes gdbarch to use the "predefault" to initialize its members
inline.  This required changing a couple of the Value instantiations
to avoid a use of "gdbarch" during initialization, but on the whole I
think this is better -- it removes a hidden ordering dependency.

Fix regression in pointer-to-member printing

PR c++/29243 points out that "info func" on a certain C++ executable
will cause an infinite loop in gdb.

I tracked this down to a bug introduced by commit 6b5a7bc76 ("Handle
member pointers directly in generic_value_print").  Before this
commit, the C++ code to print a member pointer would wind up calling
value_print_scalar_formatted; but afterward it simply calls
generic_value_print and gets into a loop.

This patch restores the previous behavior and adds a regression test.