x86: convert testcases to use .insn

This can't be done for all insns currently encoded with .byte. For one
outside of 64-bit mode unused (typically ignored) register encoding bits
in VEX/XOP/EVEX prefixes can't be set to their non-default values, since
the necessary registers cannot be specified (and some of these bits
can't even be used outside of 64-bit mode). And then there are odd tests
like the first one in bad-bcast.s: Its purpose is to illegaly set EVEX.b
together with EVEX.W (which could be expressed; note though EVEX.W set
is invalid on its own), but then it also clears EVEX.B and EVEX.R' plus
it sets EVEX.vvvv to other than 0xf (rendering the test ambiguous,
because that's another #UD reason).

In {,x86-64-}disassem.s many bogus encodings exist - some with ModR/M
byte but insufficient displacement bytes, some using SIB encoding with
the SIB byte actually being the supposed immediate. Some of these could
be expressed by .insn, but I don't want to introduce bogus examples.
These will all need adjustment anyway once the disassembler is improved
in the way it deals with unrecognized encodings.

Generally generated code is meant to remain the same. {,x86-64-}nops.d
are exceptions because insn prefixes are emitted in a different order.
opcode{,-intel,-suffix}.d are also adjusted (along with an according
correction to opcode.s) to cover an apparent typo in the original tests
(xor when or was meant).

Where necessary --divide is added as gas option, to allow for the use
of the extension opcode functionality.

Comments are being adjusted where obviously wrong/misleading.

x86: document .insn

... and mention its introduction in NEWS.

x86: handle immediate operands for .insn

Since we have no insn suffix and it's also not realistic to infer
immediate size from the size of other (typically register) operands
(like optimize_imm() does), and since we also don't have a template
telling us permitted size(s), a new syntax construct is introduced to
allow size (and signedness) specification. In the absence of such, the
size is inferred from significant bits (which obviously may yield
inconsistent results at least for effectively negative values, depending
on whether BFD64 is enabled), and only if supplied expressions can be
evaluated at parsing time. Being explicit is generally recommended to
users.

Size specification is permitted at bit granularity, but of course the
eventually emitted immediate values will be padded up to 8-, 16-, 32-,
or 64-bit fields.

x86: allow for multiple immediates in output_disp()

.insn isn't going to have a constraint of only a single immediate when,
in particular, RIP-relative addressing is used.

x86: handle EVEX Disp8 for .insn

In particular the scaling factor cannot always be determined from pre-
existing operand attributes. Introduce a new {:d<N>} vector operand
syntax extension, restricted to .insn only, to allow specifying this in
(at least) otherwise ambiguous cases.

x86: process instruction operands for .insn

Deal with register and memory operands; immediate operands will follow
later, as will the handling of EVEX embedded broadcast and EVEX Disp8
scaling.

Note that because we can't really know how to encode their use, %cr8 and
up cannot be used with .insn outside of 64-bit mode. Users would need to
specify an explicit LOCK prefix in combination with %cr0 etc.

x86: parse special opcode modifiers for .insn

So called "short form" encoding is specified by a trailing "+r", whereas
a possible extension opcode is specified by the usual "/<digit>". Take
these off the expression before handing it to get_absolute_expression().

Note that on targets where / starts a comment, --divide needs passing to
gas in order to make use of the extension opcode functionality.

x86: parse VEX and alike specifiers for .insn

All encoding spaces can be used this way; there's a certain risk that
the bits presently reserved could be used for other purposes down the
road, but people using .insn are expected to know what they're doing
anyway. Plus this way there's at least _some_ way to have those bits
set.

For now this will only allow operand-less insns to be encoded this way.

x86: introduce .insn directive

For starters this deals with only very basic constructs.

Arm64/ELF: accept relocations against STN_UNDEF

While only a secondary issue there, the testcase of PR gas/27212 exposes
an oversight in relocation handling: Just like e.g. Arm32, which has a
similar comment and a similar check, relocations against STN_UNDEF have
to be permitted to satisfy the ELF spec.

Automatic date update in version.in

PR gdb/30219: Clear sync_quit_force_run in quit_force

PR 30219 shows an internal error due to a "Bad switch" in
print_exception() in gdb/exceptions.c.  The switch in question
contains cases for RETURN_QUIT and RETURN_ERROR, but is missing a case
for the recently added RETURN_FORCED_QUIT.  This commit adds that case.

Making the above change allows the errant test case to pass, but does
not fix the underlying problem, which I'll describe shortly.  Even
though the addition of a case for RETURN_FORCED_QUIT isn't the actual
fix, I still think it's important to add this case so that other
situations which lead to print_exeption() being called won't generate
that "Bad switch" internal error.

In order to understand the underlying problem, please examine
this portion of the backtrace from the bug report:

0x5576e4ff5780 print_exception
        /home/smarchi/src/binutils-gdb/gdb/exceptions.c:100
0x5576e4ff5930 exception_print(ui_file*, gdb_exception const&)
        /home/smarchi/src/binutils-gdb/gdb/exceptions.c:110
0x5576e6a896dd quit_force(int*, int)
        /home/smarchi/src/binutils-gdb/gdb/top.c:1849

The real problem is in quit_force; here's the try/catch which
eventually leads to the internal error:

  /* Get out of tfind mode, and kill or detach all inferiors.  */
  try
    {
      disconnect_tracing ();
      for (inferior *inf : all_inferiors ())
kill_or_detach (inf, from_tty);
    }
  catch (const gdb_exception &ex)
    {
      exception_print (gdb_stderr, ex);
    }

While running the calls in the try-block, a QUIT check is being
performed.  This check finds that sync_quit_force_run is (still) set,
causing a gdb_exception_forced_quit to be thrown.  The exception
gdb_exception_forced_quit is derived from gdb_exception, causing
exception_print to be called.  As shown by the backtrace,
print_exception is then called, leading to the internal error.

The actual fix, also implemented by this commit, is to clear
sync_quit_force_run along with the quit flag.  This will allow the
various cleanup code, called by quit_force, to run without triggering
a gdb_exception_forced_quit.  (Though, if another SIGTERM is sent to
the gdb process, these flags will be set again and a QUIT check in the
cleanup code will detect it and throw the exception.)

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

aarch64: Remove stray reglist variable

Sorry for not catching this during testing.  I was using a
host compiler that predated the switch to -fno-common.

aarch64: Add the RPRFM instruction

This patch adds the RPRFM (range prefetch) instruction.
It was introduced as part of SME2, but it belongs to the
prefetch hint space and so doesn't require any specific
ISA flags.

The aarch64_rprfmop_array initialiser (deliberately) only
fills in the leading non-null elements.

aarch64: Add the SVE FCLAMP instruction

aarch64: Add new SVE shift instructions

This patch adds the new SVE SQRSHRN, SQRSHRUN and UQRSHRN
instructions.

aarch64: Add new SVE saturating conversion instructions

This patch adds the SVE SQCVTN, SQCVTUN and UQCVTN instructions,
which are available when FEAT_SME2 is implemented.

aarch64: Add new SVE dot-product instructions

This patch adds the SVE FDOT, SDOT and UDOT instructions,
which are available when FEAT_SME2 is implemented.  The patch
also reorders the existing SVE_Zm3_22_INDEX to keep the
operands numerically sorted.

aarch64: Add the SVE BFMLSL instructions

This patch adds the SVE BFMLSLB and BFMLSLT instructions,
which are available when FEAT_SME2 is implemented.

aarch64: Add the SME2 UZP and ZIP instructions

This patch adds UZP and ZIP, which combine UZP{1,2} and ZIP{1,2}
into single instructions.

aarch64: Add the SME2 UNPK instructions

This patch adds SUNPK and UUNPK, which unpack one register's
worth of elements to two registers' worth, or two registers'
worth to four registers' worth.

aarch64: Add the SME2 shift instructions

There are two instruction formats here:

- SQRSHR, SQRSHRU and UQRSHR, which operate on lists of two
  or four registers.

- SQRSHRN, SQRSHRUN and UQRSHRN, which operate on lists of
  four registers.

These are the first SME2 instructions to have immediate operands.
The patch makes sure that, when parsing SME2 instructions with
immediate operands, the new predicate-as-counter registers are
parsed as registers rather than as #-less immediates.

aarch64: Add the SME2 saturating conversion instructions

There are two instruction formats here:

- SQCVT, SQCVTU and UQCVT, which operate on lists of two or
  four registers.

- SQCVTN, SQCVTUN and UQCVTN, which operate on lists of
  four registers.

aarch64: Add the SME2 FP<->FP conversion instructions

This patch adds the BFCVT{,N} and FCVT{,N} instructions,
which narrow a pair of .S registers to a single .H register.

aarch64: Add the SME2 FP<->int conversion instructions

This patch adds the SME2 versions of the FP<->integer conversion
instructions FCVT* and *CVTF.  It also adds FP rounding instructions
FRINT*, which share the same format.

aarch64: Add the SME2 CLAMP instructions

FCLAMP, SCLAMP and UCLAMP share the same format, although FCLAMP
doesn't have a .B form.

aarch64: Add the SME2 MOPA and MOPS instructions

[BSU]MOP[AS] share the same format.

aarch64: Add the SME2 vertical dot-product instructions

There are three instruction formats here:
- BFVDOT + FVDOT
- SVDOT + UVDOT
- SUVDOT + USVDOT

There are also 64-bit forms of SVDOT and UVDOT.

aarch64: Add the SME2 dot-product instructions

BFDOT, FDOT and USDOT share the same instruction format.
SDOT and UDOT share a different format.  SUDOT does not
have the multi vector x multi vector forms, since they
would be redundant with USDOT.

aarch64: Add the SME2 MLALL and MLSLL instructions

SMLALL, SMLSLL, UMLALL and UMLSLL have the same format.
USMLALL and SUMLALL allow the same operand types as those
instructions, except that SUMLALL does not have the multi-vector
x multi-vector forms (which would be redundant with USMLALL).

aarch64: Add the SME2 MLAL and MLSL instructions

The {BF,F,S,U}MLAL and {BF,F,S,U}MLSL instructions share the same
encoding.  They are the first instance of a ZA (as opposed to ZA tile)
operand having a range of offsets.  As with ZA tiles, the expected
range size is encoded in the operand-specific data field.

aarch64: Add the SME2 FMLA and FMLS instructions

aarch64: Add the SME2 maximum/minimum instructions

This patch adds the SME2 multi-register forms of F{MAX,MIN}{,NM}
and {S,U}{MAX,MIN}.  SQDMULH, SRSHL and URSHL have the same form
as SMAX etc., so the patch adds them too.

aarch64: Add the SME2 ADD and SUB instructions

Add support for the SME2 ADD. SUB, FADD and FSUB instructions.
SUB and FSUB have the same form as ADD and FADD, except that
ADD also has a 2-operand accumulating form.

The 64-bit ADD/SUB instructions require FEAT_SME_I16I64 and the
64-bit FADD/FSUB instructions require FEAT_SME_F64F64.

These are the first instructions to have tied register list
operands, as opposed to tied single registers.

The parse_operands change prevents unsuffixed Z registers (width==-1)
from being treated as though they had an Advanced SIMD-style suffix
(.4s etc.).  It means that:

  Error: expected element type rather than vector type at operand 2 -- `add za\.s\[w8,0\],{z0-z1}'

becomes:

  Error: missing type suffix at operand 2 -- `add za\.s\[w8,0\],{z0-z1}'

aarch64: Add the SME2 ZT0 instructions

SME2 adds lookup table instructions for quantisation.  They use
a new lookup table register called ZT0.

LUTI2 takes an unsuffixed SVE vector index of the form Zn[<imm>],
which is the first time that this syntax has been used.

aarch64: Add the SME2 predicate-related instructions

Implementation-wise, the main things to note here are:

- the WHILE* instructions have forms that return a pair of predicate
  registers.  This is the first time that we've had lists of predicate
  registers, and they wrap around after register 15 rather than after
  register 31.

- the predicate-as-counter WHILE* instructions have a fourth operand
  that specifies the vector length.  We can treat this as an enumeration,
  except that immediate values aren't allowed.

- PEXT takes an unsuffixed predicate index of the form PN<n>[<imm>].
  This is the first instance of a vector/predicate index having
  no suffix.

aarch64: Add the SME2 multivector LD1 and ST1 instructions

SME2 adds LD1 and ST1 variants for lists of 2 and 4 registers.
The registers can be consecutive or strided.  In the strided case,
2-register lists have a stride of 8, starting at register x0xxx.
4-register lists have a stride of 4, starting at register x00xx.

The instructions are predicated on a predicate-as-counter register in
the range pn8-pn15.  Although we already had register fields with upper
bounds of 7 and 15, this is the first plain register operand to have a
nonzero lower bound.  The patch uses the operand-specific data field
to record the minimum value, rather than having separate inserters
and extractors for each lower bound.  This in turn required adding
an extra bit to the field.

aarch64: Add the SME2 MOVA instructions

SME2 defines new MOVA instructions for moving multiple registers
to and from ZA.  As with SME, the instructions are also available
through MOV aliases.

One notable feature of these instructions (and many other SME2
instructions) is that some register lists must start at a multiple
of the list's size.  The patch uses the general error "start register
out of range" when this constraint isn't met, rather than an error
specifically about multiples.  This ensures that the error is
consistent between these simple consecutive lists and later
strided lists, for which the requirements aren't a simple multiple.

aarch64: Add support for predicate-as-counter registers

SME2 adds a new format for the existing SVE predicate registers:
predicates as counters rather than predicates as masks.  In assembly
code, operands that interpret predicates as counters are written
pn<N> rather than p<N>.

This patch adds support for these registers and extends some
existing instructions to support them.  Since the new forms
are just a programmer convenience, there's no need to make them
more restrictive than the earlier predicate-as-mask forms.

aarch64; Add support for vector offset ranges

Some SME2 instructions operate on a range of consecutive ZA vectors.
This is indicated by syntax such as:

   za[<Wv>, <imml>:<immh>]

Like with the earlier vgx2 and vgx4 support, we get better error
messages if the parser allows all ZA indices to have a range.
We can then reject invalid cases during constraint checking.

aarch64: Add support for vgx2 and vgx4

Many SME2 instructions operate on groups of 2 or 4 ZA vectors.
This is indicated by adding a "vgx2" or "vgx4" group size to the
ZA index.  The group size is optional in assembly but preferred
for disassembly.

There is not a binary distinction between mnemonics that have
group sizes and mnemonics that don't, nor between mnemonics that
take vgx2 and mnemonics that take vgx4.  We therefore get better
error messages if we allow any ZA index to have a group size
during parsing, and wait until constraint checking to reject
invalid sizes.

A quirk of the way errors are reported means that if an instruction
is wrong both in its qualifiers and its use of a group size, we'll
print suggested alternative instructions that also have an incorrect
group size.  But that's a general property that also applies to
things like out-of-range immediates.  It's also not obviously the
wrong thing to do.  We need to be relatively confident that we're
looking at the right opcode before reporting detailed operand-specific
errors, so doing qualifier checking first seems resonable.

aarch64: Add _off4 suffix to AARCH64_OPND_SME_ZA_array

SME2 adds various new fields that are similar to
AARCH64_OPND_SME_ZA_array, but are distinguished by the size of
their offset fields.  This patch adds _off4 to the name of the
field that we already have.

aarch64: Add a _10 suffix to FLD_imm3

SME2 adds various new 3-bit immediate fields, so this patch adds
an lsb position suffix to the name of the field that we already have.

aarch64: Add +sme2

This patch adds bare-bones support for +sme2.  Later patches
fill in the rest.

aarch64: Prefer register ranges & support wrapping

Until now, binutils has supported register ranges such
as { v0.4s - v3.4s } as an unofficial shorthand for
{ v0.4s, v1.4s, v2.4s, v3.4s }.  The SME2 ISA embraces this form
and makes it the preferred disassembly.  It also embraces wrapped
lists such as { z31.s - z2.s }, which is something that binutils
didn't previously allow.

The range form was already binutils's preferred disassembly for 3- and
4-register lists.  This patch prefers it for 2-register lists too.
The patch also adds support for wrap-around.

aarch64: Add support for strided register lists

SME2 has instructions that accept strided register lists,
such as { z0.s, z4.s, z8.s, z12.s }.  The purpose of this
patch is to extend binutils to support such lists.

The parsing code already had (unused) support for strides of 2.
The idea here is instead to accept all strides during parsing
and reject invalid strides during constraint checking.

The SME2 instructions that accept strided operands also have
non-strided forms.  The errors about invalid strides therefore
take a bitmask of acceptable strides, which allows multiple
possibilities to be summed up in a single message.

I've tried to update all code that handles register lists.

aarch64: Sort fields alphanumerically

This patch just sorts the field enum alphanumerically, which makes
it easier to see if a particular field has already been defined.

aarch64: Resync field names

This patch just makes the comments in aarch64-opc.c:fields match
the names of the associated FLD_* enum.

aarch64: Regularise FLD_* suffixes

Some FLD_imm* suffixes used a counting scheme such as FLD_immN,
FLD_immN_2, FLD_immN_3, etc., while others used the lsb as the
suffix.  The latter seems more mnemonic, and was a big help
in doing the SME2 work.

Similarly, the _10 suffix on FLD_SME_size_10 was nonobvious.
Presumably it indicated a 2-bit field, but it actually starts
in bit 22.

aarch64: Rename some of GAS's REG_TYPE_* macros

In GAS, the vector and predicate registers are identified by
REG_TYPE_VN, REG_TYPE_ZN and REG_TYPE_PN.  This "N" is obviously
a placeholder for the register number.  However, we don't use that
convention for integer and FP registers, and (more importantly)
SME2 adds "predicate-as-counter" registers that are denoted PN.

This patch therefore drops the "N" suffix from the existing
registers.  The main hitch is that Z was also used for the
zero register in things like R_Z, but using ZR seems more
consistent with the SP-based names.

aarch64: Add a aarch64_cpu_supports_inst_p helper

Quite a lot of SME2 instructions have an opcode bit that selects
between 32-bit and 64-bit forms of an instruction, with the 32-bit
forms being part of base SME2 and with the 64-bit forms being part
of an optional extension.  It's nevertheless useful to have a single
opcode entry for both forms since (a) that matches the ISA definition
and (b) it tends to improve error reporting.

This patch therefore adds a libopcodes function called
aarch64_cpu_supports_inst_p that tests whether the target
supports a particular instruction.  In future it will depend
on internal libopcodes routines.

aarch64: Reorder some OP_SVE_* macros

This patch just moves some out-of-order-looking OP_SVE_* macros.

aarch64: Rename aarch64-tbl.h OP_SME_* macros

This patch renames the OP_SME_* macros in aarch64-tbl.h so that
they follow the same scheme as the OP_SVE_* ones.  It also uses
OP_SVE_ as the prefix, since there is no real distinction between
the SVE and SME uses of qualifiers: a macro defined for one can
be useful for the other too.

aarch64: Tweak priorities of parsing-related errors

There are three main kinds of error reported during parsing,
in increasing order of priority:

- AARCH64_OPDE_RECOVERABLE (register seen instead of immediate)
- AARCH64_OPDE_SYNTAX_ERROR
- AARCH64_OPDE_FATAL_SYNTAX_ERROR

This priority makes sense when comparing errors reported against the
same operand.  But if we get to operand 3 (say) and see a register
instead of an immediate, that's likely to be a better match than
something that fails with a syntax error at operand 1.

The idea of this patch is to prioritise parsing-related errors
based on operand index first, then by error code.  Post-parsing
errors still win over parsing errors, and their relative priorities
don't change.

aarch64: Try to report invalid variants against the closest match

If an instruction has invalid qualifiers, GAS would report the
error against the final opcode entry that got to the qualifier-
checking stage.  It seems better to report the error against
the opcode entry that had the closest match, just like we
pick the closest match within an opcode entry for the
"did you mean this?" message.

This patch adds the number of invalid operands as an
argument to AARCH64_OPDE_INVALID_VARIANT and then picks the
AARCH64_OPDE_INVALID_VARIANT with the lowest argument.

aarch64: Tweak register list errors

The error for invalid register lists had the form:

  invalid number of registers in the list; N registers are expected at operand M -- `insn'

This seems a bit verbose.  Also, the "bracketing" is really:

  (invalid number of registers in the list; N registers are expected) at operand M

but the semicolon works against that.

This patch goes for slightly shorter messages, setting a template
that later patches can use for more complex cases.

aarch64: Make AARCH64_OPDE_REG_LIST take a bitfield

AARCH64_OPDE_REG_LIST took a single operand that specified the
expected number of registers.  However, there are quite a few
SME2 instructions that have both 2-register forms and (separate)
4-register forms.  If the user tries to use a 3-register list,
it isn't obvious which opcode entry they meant.  Saying that we
expect 2 registers and saying that we expect 4 registers would
both be wrong.

This patch therefore switches the operand to a bitfield.  If a
AARCH64_OPDE_REG_LIST is reported against multiple opcode entries,
the patch ORs up the expected lengths.

This has no user-visible effect yet.  A later patch adds more error
strings, alongside tests that use them.

aarch64: Add an operand class for SVE register lists

SVE register lists were classified as SVE_REG, since there had been
no particular reason to separate them out.  However, some SME2
instructions have tied register list operands, and so we need to
distinguish registers and register lists when checking whether two
operands match.

Also, the register list operands used a general error message,
even though we already have a dedicated error code for register
lists that are the wrong length.

aarch64: Commonise checks for index operands

This patch splits out the constraint checking for index operands,
so that it can be reused by new SME2 operands.

aarch64: Add an error code for out-of-range registers

libopcodes currently reports out-of-range registers as a general
AARCH64_OPDE_OTHER_ERROR.  However, this means that each register
range needs its own hard-coded string, which is a bit cumbersome
if the range is determined programmatically.  This patch therefore
adds a dedicated error type for out-of-range errors.

aarch64: Deprioritise AARCH64_OPDE_REG_LIST

SME2 has many instructions that take a list of SVE registers.
There are often multiple forms, with different forms taking
different numbers of registers.

This means that if, after a successful parse and qualifier match,
we find that the number of registers does not match the opcode entry,
the associated error should have a lower priority/severity than other
errors reported at the same stage.  For example, if there are 2-register
and 4-register forms of an instruction, and if the assembly code uses
the 2-register form with an out-of-range value, the out-of-range value
error against the 2-register instruction should have a higher priority
than the "wrong number of registers" error against the 4-register
instruction.

This is tested by the main SME2 patches, but seemed worth splitting out.

aarch64: Update operand_mismatch_kind_names

The contents of operand_mismatch_kind_names were out of sync
with the enum.

aarch64: Rework reporting of failed register checks

There are many opcode table entries that share the same mnemonic.
Trying to parse an invalid assembly line will trigger an error for
each of these entries, but the specific error might vary from one
entry to another, depending on the exact nature of the problem.

GAS has quite an elaborate system for picking the most appropriate
error out of all the failed matches.  And in many cases it works well.
However, one of the limitations is that the error is always reported
against a single opcode table entry.  If that table entry isn't the
one that the user intended to use, then the error can end up being
overly specific.

This is particularly true if an instruction has a typoed register
name, or uses a type of register that is not accepted by any
opcode table entry.  For example, one of the expected error
matches for an attempted SVE2 instruction is:

  Error: operand 1 must be a SIMD scalar register -- `addp z32\.s,p0/m,z32\.s,z0\.s'

even though the hypothetical user was presumably attempting to use
the SVE form of ADDP rather than the Advanced SIMD one.  There are
many other instances of this in the testsuite.

The problem becomes especially acute with SME2, since many SME2
instructions reuse existing mnemonics.  This could lead to us
reporting an SME-related error against a non-SME instruction,
or a non-SME-related error against an SME instruction.

This patch tries to improve things by collecting together all
the register types that an opcode table entry expected for a
given operand.  It also records what kind of register was
actually seen, if any.  It then tries to summarise all this
in a more directed way, falling back to a generic error if
the combination defies a neat summary.

The patch includes tests for all new messages except REG_TYPE_ZA,
which only triggers with SME2.

To test this, I created an assembly file that contained the cross
product of all known mnemonics and one example from each register
class.  I then looked for cases where the new routines fell back on the
generic errors ("expected a register" or "unexpected register type").
I locally added dummy messages for each one until there were no
more hits.  The patch adds a specimen instruction to diagnostics.s
for each of these combinations.  In each case, the combination didn't
seem like something that could be summarised in a natural way, so the
generic messages seemed better.  There's always going to be an element
of personal taste around this kind of thing though.

Adding more register types made 1<<REG_TYPE_MAX exceed the range
of the type, but we don't actually need/want 1<<REG_TYPE_MAX.

aarch64: Try to avoid inappropriate default errors

After parsing a '{' and the first register, parse_typed_reg would
report errors in subsequent registers in the same way as for the
first register.  It used set_default_error, which reports errors
of the form "operand N must be X".

The problem is that if there are multiple opcode entries for the
same mnemonic, there could be several matches that lead to a
default error.  There's no guarantee that the default error for
the register list is the one that will be chosen.

To take an example from the testsuite:

    ext z0.b,{z31.b,z32.b},#0

gave:

    operand 2 must be an SVE vector register

with the error being reported against the single-vector version
of ext, even though the operand is clearly a list.

This patch uses set_fatal_syntax_error to bump the priority of the
error once we're sure that the operand is a list of the right type.

aarch64: Improve errors for malformed register lists

parse_typed_reg is used for parsing both bare registers and
registers that occur in lists.  If it doesn't see a register,
or sees an unexpected kind of register, it queues a default
error to report the problem.  These default errors have the form
"operand N must be an X", where X comes from the operand table.

If there are multiple opcode entries that report default errors,
GAS tries to pick the most appropriate one, using the opcode
table order as a tiebreaker.  But this can lead to cases where
a syntax error in a register list is reported against an opcode
that doesn't accept register lists.  For example, the unlikely
error:

  ext z0.b,{,},#0

is reported as:

  operand 2 must be an SVE vector register -- `ext z0.b,{,},#0'

even though operand 2 can be a register list.

If we've parsed the opening '{' of a register list, and then see
something that isn't remotely register-like, it seems better to
report that directly as a syntax error, rather than rely on the
default error.  The operand won't be a valid list of anything,
so there's no need to pick a specific Y in "operand N must be
a list of Y".

aarch64: Tweak parsing of integer & FP registers

Integer registers were parsed indirectly through
aarch64_reg_parse_32_64 (and thus aarch64_addr_reg_parse) rather
than directly through parse_reg.  This was because we need the
qualifier associated with the register, and the logic to calculate
that was buried in aarch64_addr_reg_parse.

The code that parses FP registers had the same need, but it
open-coded the calculation of the qualifier.

This patch tries to handle both cases in the same way.  It is
needed by a later patch that tries to improve the register-related
diagnostics.

aarch64: Tweak errors for base & offset registers

parse_address_main currently uses get_reg_expected_msg to
report invalid base and offset registers, but the disadvantage
of doing that is that it isn't immediately clear which register
is wrong (the base or the offset).

A later patch moves away from using get_reg_expected_msg for failed
type checks, but doing that here didn't seem like the best approach.
The patch tries to use more tailored messages instead.

aarch64: Tweak error for missing immediate offset

This patch tweaks the error message that is printed when
a ZA-style index is missing the immediate offset.

aarch64: Move w12-w15 range check to libopcodes

In SME, the vector select register had to be in the range
w12-w15, so it made sense to enforce that during parsing.
However, SME2 adds instructions for which the range is
w8-w11 instead.

This patch therefore moves the range check from the parsing
stage to the constraint-checking stage.

Also, the previous error used a capitalised range W12-W15,
whereas other register range errors used lowercase ranges
like p0-p7.  A quick internal poll showed a preference for
the lowercase form, so the patch uses that.

The patch uses "selection register" rather than "vector
select register" so that the terminology extends more
naturally to PSEL.

aarch64: Commonise index parsing

Just a minor clean-up to factor out the index parsing, partly to
ensure that the error handling remains consistent.  No behavioural
change intended.

aarch64: Consolidate ZA slice parsing

Now that parse_typed_reg checks the range of tile register numbers
and libopcodes checks the range of vector select offsets, there's
very little difference between the parsing of ZA tile indices,
ZA array indices, and PSEL indices.  The main one is that ZA
array indices don't currently allow "za" to be qualified,
but we need to remove that restriction for SME2.

This patch therefore consolidates all three parsers into a single
routine, parameterised by the type of register that they expect.

aarch64: Move ZA range checks to aarch64-opc.c

This patch moves the range checks on ZA vector select offsets from
gas to libopcodes.  Doing the checks there means that the error
messages contain the expected range.  It also fits in better
with the error severity scheme, which becomes important later.
(This is because out-of-range indices are treated as more severe than
syntax errors, on the basis that parsing must have succeeded if we get
to the point of checking the completed opcode.)

The patch also adds a new check_za_access function for checking
ZA accesses.  That's a bit over the top for one offset check, but the
function becomes more complex with later patches.

sme-9-illegal.s checked for an invalid .q suffix using:

  psel p1, p15, p3.q[w15]

but this is doubly invalid because it misses the immediate part
of the index.  The patch keeps that test but adds another with
a zero index, so that .q is the only thing wrong.

The aarch64-tbl.h change includes neatening up the backslash
positions.

aarch64: Pass aarch64_indexed_za to parsers

ZA indices have more parts than most operands, so passing these
parts around individually is more awkward than for other operand
types.  Things aren't too bad at the moment, but SME2 adds two
further pieces: an offset range and a vector group size.

This patch therefore replaces arguments for the individual pieces
with a single argument for the index as a whole.

aarch64: Make indexed_za use 64-bit immediates

A later patch moves the range checking for ZA vector select
offsets from gas to libopcodes.  That in turn requires the
immediate field to be big enough to support all parsed values.

This shouldn't be a particularly size-sensitive structure,
so there should be no memory problems with doing this.

aarch64: Rename za_tile_vector to za_index

za_tile_vector is also used for indexing ZA as a whole, rather than
just for indexing tiles.  The former is more common than the latter
in SME2, so this patch generalises the name to "indexed_za".

The patch also names the associated structure, so that later patches
can reuse it during parsing.

aarch64: Treat ZA as a register

We already treat the ZA tiles ZA0-ZA15 as registers.  This patch
does the same for ZA itself.  parse_sme_zero_mask can then parse
ZA tiles and ZA in the same way, through parsed_type_reg.

One important effect of going through parsed_type_reg (in general)
is that it allows ZA to take qualifiers.  This is necessary for many
SME2 instructions.

However, to support existing unqualified uses of ZA, parse_reg_with_qual
needs to treat the qualiier as optional.  Hopefully the net effect is
to give better error messages, since now that SME2 makes "za.<T>"
valid in some contexts, it might be natural to use it (incorrectly)
in ZERO too.

While there, the patch also tweaks the error messages for invalid
ZA tiles, to try to make some cases more specific.

For now, parse_sme_za_array just uses parse_reg, rather than
parse_typed_reg/parse_reg_with_qual.  A later patch consolidates
the parsing further.

aarch64: Consolidate ZA tile range checks

Now that all parsing of ZA tile names goes through parse_typed_reg,
we can check there for out-of-range tile numbers.  The other check
performed by parse_sme_zada_operand was to reject .q, but that can
now be done via F_STRICT instead.  (.q tiles are valid in other
contexts, so they shouldn't be rejected in parse_typed_reg.)

aarch64: Reuse parse_typed_reg for ZA tiles

This patch reuses the general parse_typed_reg for ZA tiles.
This involves adding a way of suppressing the usual treatment
of register indices, since ZA indices look very different from
Advanced SIMD and SVE vector indices.

aarch64: Rework parse_typed_reg interface

parse_typed_reg returned a register number and passed the
register type back using a pointer parameter.  It seems simpler
to return the register entry instead, since that has both pieces
of information in one place.

The patch also replaces the boolean in_reg_list parameter with
a mask of flags.  This hopefully makes calls easier to read
(more self-documenting than "true" or "false"), but more
importantly, it allows a later patch to add a second flag.

aarch64: Move vectype_to_qualifier further up

This patch just moves vectype_to_qualifier further up, so that
a later patch can call it at an earlier point in the file.
No behavioural change intended.

aarch64: Add REG_TYPE_ZATHV

This patch adds a multi-register type that includes both REG_TYPE_ZATH
and REG_TYPE_ZATV.  This slightly simplifies the existing code, but the
main purpose is to enable later patches.

aarch64: Rename REG_TYPE_ZA* to REG_TYPE_ZAT*

The ZA tile registers were called REG_TYPE_ZA, REG_TYPE_ZAH and
REG_TYPE_ZAV.  However, a later patch wants to make plain "za"
a register type too, and REG_TYPE_ZA is the obvious name for that.

This patch therefore adds "T" (tile) to the existing names.

aarch64: Use aarch64_operand_error more widely

GAS's aarch64_instruction had its own cut-down error record,
but it's better for later patches if it reuses the binutils-wide
aarch64_operand_error instead.  The main difference is that
aarch64_operand_error can store arguments to the error while
aarch64_instruction couldn't.

aarch64: Make SME instructions use F_STRICT

This patch makes all SME instructions use F_STRICT, so that qualifiers
have to be provided explicitly rather than being inferred from other
operands.  The main change is to move the qualifier setting from the
operand-level decoders to the opcode level.

This is one step towards consolidating the ZA parsing code and
extending it to handle SME2.

aarch64: Fix SVE2 register/immediate distinction

GAS refuses to interpret register names like x0 as unadorned
immediates, due to the obvious potential for confusion with
register operands.  (An explicit #x0 is OK.)

For compatibility reasons, we can't extend the set of registers
that GAS rejects for existing instructions.  For example:

   mov x0, z0

was valid code before SVE was added, so it needs to stay valid
code even when SVE is enabled.  But we can make GAS reject newer
registers in newer instructions.  The SVE instruction:

   and z0.s, z0.s, z0.h

is therefore invalid, rather than z0.h being an immediate.

This patch extends the SVE behaviour to SVE2.  The old call
to AARCH64_CPU_HAS_FEATURE was technically the wrong way around,
although it didn't matter in practice for base SVE instructions
since their avariants only set SVE.

aarch64: Restrict range of PRFM opcodes

In the register-index forms of PRFM, the unallocated prefetch opcodes
24-31 have been reused for the encoding of the new RPRFM instruction.
The PRFM opcode space is now capped at 23 for these forms.  The other
forms of PRFM are unaffected.

aarch64: Fix PSEL opcode mask

The opcode mask for PSEL was missing some bits, which meant
that some upcoming SME2 opcodes would be misinterpreted as PSELs.

aarch64: Add sme-i16i64 and sme-f64f64 aliases

Most extension flags are named after the associated architectural
FEAT_* flags, but sme-i64 and sme-f64 were exceptions.  This patch
adds sme-i16i64 and sme-f64f64 aliases, but keeps the old names too
for compatibility.

Fix an illegal memory access triggered by parsing corrupt DWARF info.

  PR 30284
  * dwarf.c (read_and_display_attr_value): Detect and ignore negative base values.

gdb/python: Add new gdb.unwinder.FrameId class

When writing an unwinder it is necessary to create a new class to act
as a frame-id.  This new class is almost certainly just going to set a
'sp' and 'pc' attribute within the instance.

This commit adds a little helper class gdb.unwinder.FrameId that does
this job.  Users can make use of this to avoid having to write out
standard boilerplate code any time they write an unwinder.

Of course, if the user wants their FrameId class to be more
complicated in some way, then they can still write their own class,
just like they could before.

I've simplified the example code in the documentation to now use the
new helper class, and I've also made use of this helper within the
testsuite.

Any existing user code will continue to work just as it did before
after this change.

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

gdb/python: Allow gdb.UnwindInfo to be created with non gdb.Value args

Currently when creating a gdb.UnwindInfo object a user must call
gdb.PendingFrame.create_unwind_info and pass a frame-id object.

The frame-id object should have at least a 'sp' attribute, and
probably a 'pc' attribute too (it can also, in some cases have a
'special' attribute).

Currently all of these frame-id attributes need to be gdb.Value
objects, but the only reason for that requirement is that we have some
code in py-unwind.c that only handles gdb.Value objects.

If instead we switch to using get_addr_from_python in py-utils.c then
we will support both gdb.Value objects and also raw numbers, which
might make things simpler in some cases.

So, I started rewriting pyuw_object_attribute_to_pointer (in
py-unwind.c) to use get_addr_from_python.  However, while looking at
the code I noticed a problem.

The pyuw_object_attribute_to_pointer function returns a boolean flag,
if everything goes OK we return true, but we return false in two
cases, (1) when the attribute is not present, which might be
acceptable, or might be an error, and (2) when we get an error trying
to extract the attribute value, in which case a Python error will have
been set.

Now in pending_framepy_create_unwind_info we have this code:

  if (!pyuw_object_attribute_to_pointer (pyo_frame_id, "sp", &sp))
    {
      PyErr_SetString (PyExc_ValueError,
       _("frame_id should have 'sp' attribute."));
      return NULL;
    }

Notice how we always set an error.  This will override any error that
is already set.

So, if you create a frame-id object that has an 'sp' attribute, but
the attribute is not a gdb.Value, then currently we fail to extract
the attribute value (it's not a gdb.Value) and set this error in
pyuw_object_attribute_to_pointer:

  rc = pyuw_value_obj_to_pointer (pyo_value.get (), addr);
  if (!rc)
    PyErr_Format (
        PyExc_ValueError,
        _("The value of the '%s' attribute is not a pointer."),
        attr_name);

Then we return to pending_framepy_create_unwind_info and immediately
override this error with the error about 'sp' being missing.

This all feels very confused.

Here's my proposed solution: pyuw_object_attribute_to_pointer will now
return a tri-state enum, with states OK, MISSING, or ERROR.  The
meanings of these states are:

  OK - Attribute exists and was extracted fine,

  MISSING - Attribute doesn't exist, no Python error was set.

  ERROR - Attribute does exist, but there was an error while
     extracting it, a Python error was set.

We need to update pending_framepy_create_unwind_info, the only user of
pyuw_object_attribute_to_pointer, but now I think things are much
clearer.  Errors from lower levels are not blindly overridden with the
generic meaningless error message, but we still get the "missing 'sp'
attribute" error when appropriate.

This change also includes the switch to get_addr_from_python which was
what started this whole journey.

For well behaving user code there should be no visible changes after
this commit.

For user code that hits an error, hopefully the new errors should be
more helpful in figuring out what's gone wrong.

Additionally, users can now use integers for the 'sp' and 'pc'
attributes in their frame-id objects if that is useful.

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

gdb: have value_as_address call unpack_pointer

While refactoring some other code in gdb/python/* I wanted to merge
two code paths.  One path calls value_as_address, while the other
calls unpack_pointer.

I suspect calling value_as_address is the correct choice, but, while
examining the code I noticed that value_as_address calls unpack_long
rather than unpack_pointer.

Under the hood, unpack_pointer does just call unpack_long so there's
no real difference here, but it feels like value_as_address should
call unpack_pointer.

I've updated the code to use unpack_pointer, and changed a related
comment to say that we call unpack_pointer.  I've also adjusted the
header comment on value_as_address.  The existing header refers to
some code that is now commented out.

Rather than trying to describe the whole algorithm of
value_as_address, which is already well commented within the function,
I've just trimmed the comment on value_as_address to be a brief
summary of what the function does.

There should be no user visible changes after this commit.

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

gdb/python: remove Py_TPFLAGS_BASETYPE from gdb.UnwindInfo

It is not currently possible to directly create gdb.UnwindInfo
instances, they need to be created by calling
gdb.PendingFrame.create_unwind_info so that the newly created
UnwindInfo can be linked to the pending frame.

As such there's no tp_init method defined for UnwindInfo.

A consequence of all this is that it doesn't really make sense to
allow sub-classing of gdb.UnwindInfo.  Any sub-class can't call the
parents __init__ method to correctly link up the PendingFrame
object (there is no parent __init__ method).  And any instances that
sub-classes UnwindInfo but doesn't call the parent __init__ is going
to be invalid for use in GDB.

This commit removes the Py_TPFLAGS_BASETYPE flag from the UnwindInfo
class, which prevents the class being sub-classed.  Then I've added a
test to check that this is indeed prevented.

Any functional user code will not have any issues with this change.

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

gdb/python: add __repr__ for PendingFrame and UnwindInfo

Having a useful __repr__ method can make debugging Python code that
little bit easier.  This commit adds __repr__ for gdb.PendingFrame and
gdb.UnwindInfo classes, along with some tests.

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

gdb/python: add some additional methods to gdb.PendingFrame

The gdb.Frame class has far more methods than gdb.PendingFrame.  Given
that a PendingFrame hasn't yet been claimed by an unwinder, there is a
limit to which methods we can add to it, but many of the methods that
the Frame class has, the PendingFrame class could also support.

In this commit I've added those methods to PendingFrame that I believe
are safe.

In terms of implementation: if I was starting from scratch then I
would implement many of these (or most of these) as attributes rather
than methods.  However, given both Frame and PendingFrame are just
different representation of a frame, I think there is value in keeping
the interface for the two classes the same.  For this reason
everything here is a method -- that's what the Frame class does.

The new methods I've added are:

  - gdb.PendingFrame.is_valid: Return True if the pending frame
    object is valid.

  - gdb.PendingFrame.name: Return the name for the frame's function,
    or None.

  - gdb.PendingFrame.pc: Return the $pc register value for this
    frame.

  - gdb.PendingFrame.language: Return a string containing the
    language for this frame, or None.

  - gdb.PendingFrame.find_sal: Return a gdb.Symtab_and_line object
    for the current location within the pending frame, or None.

  - gdb.PendingFrame.block: Return a gdb.Block for the current
    pending frame, or None.

  - gdb.PendingFrame.function: Return a gdb.Symbol for the current
    pending frame, or None.

In every case I've just copied the implementation over from gdb.Frame
and cleaned the code slightly e.g. NULL to nullptr.  Additionally each
function required a small update to reflect the PendingFrame type, but
that's pretty minor.

There are tests for all the new methods.

For more extensive testing, I added the following code to the file
gdb/python/lib/command/unwinders.py:

  from gdb.unwinder import Unwinder

  class TestUnwinder(Unwinder):
      def __init__(self):
          super().__init__("XXX_TestUnwinder_XXX")

      def __call__(self,pending_frame):
          lang = pending_frame.language()
          try:
              block = pending_frame.block()
              assert isinstance(block, gdb.Block)
          except RuntimeError as rte:
              assert str(rte) == "Cannot locate block for frame."
          function = pending_frame.function()
          arch = pending_frame.architecture()
          assert arch is None or isinstance(arch, gdb.Architecture)
          name = pending_frame.name()
          assert name is None or isinstance(name, str)
          valid = pending_frame.is_valid()
          pc = pending_frame.pc()
          sal = pending_frame.find_sal()
          assert sal is None or isinstance(sal, gdb.Symtab_and_line)
          return None

  gdb.unwinder.register_unwinder(None, TestUnwinder())

This registers a global unwinder that calls each of the new
PendingFrame methods and checks the result is of an acceptable type.
The unwinder never claims any frames though, so shouldn't change how
GDB actually behaves.

I then ran the testsuite.  There was only a single regression, a test
that uses 'disable unwinder' and expects a single unwinder to be
disabled -- the extra unwinder is now disabled too, which changes the
test output.  So I'm reasonably confident that the new methods are not
going to crash GDB.

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

gdb/python: add PENDING_FRAMEPY_REQUIRE_VALID macro in py-unwind.c

This commit copies the pattern that is present in many other py-*.c
files: having a single macro to check that the Python object is still
valid.

This cleans up the code a little throughout the py-unwind.c file.

Some of the exception messages will change slightly with this commit,
though the type of the exceptions is still ValueError in all cases.

I started writing some tests for this change and immediately ran into
a problem: GDB would crash.  It turns out that the PendingFrame
objects are not being marked as invalid!

In pyuw_sniffer where the pending frames are created, we make use of a
scoped_restore to invalidate the pending frame objects.  However, this
only restores the pending_frame_object::frame_info field to its
previous value -- and it turns out we never actually give this field
an initial value, it's left undefined.

So, when the scoped_restore (called invalidate_frame) performs its
cleanup, it actually restores the frame_info field to an undefined
value.  If this undefined value is not nullptr then any future
accesses to the PendingFrame object result in undefined behaviour and
most likely, a crash.

As part of this commit I now initialize the frame_info field, which
ensures all the new tests now pass.

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

gdb/python: remove unneeded nullptr check in frapy_block

Spotted a redundant nullptr check in python/py-frame.c in the function
frapy_block.  This was introduced in commit 57126e4a45e3000e when we
expanded an earlier check in return early if the pointer in question
is nullptr.

There should be no user visible changes after this commit.

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

gdb/python: make the gdb.unwinder.Unwinder class more robust

This commit makes a few related changes to the gdb.unwinder.Unwinder
class attributes:

  1. The 'name' attribute is now a read-only attribute.  This prevents
  user code from changing the name after registering the unwinder.  It
  seems very unlikely that any user is actually trying to do this in
  the wild, so I'm not very worried that this will upset anyone,

  2. We now validate that the name is a string in the
  Unwinder.__init__ method, and throw an error if this is not the
  case.  Hopefully nobody was doing this in the wild.  This should
  make it easier to ensure the 'info unwinder' command shows sane
  output (how to display a non-string name for an unwinder?),

  3. The 'enabled' attribute is now implemented with a getter and
  setter.  In the setter we ensure that the new value is a boolean,
  but the real important change is that we call
  'gdb.invalidate_cached_frames()'.  This means that the backtrace
  will be updated if a user manually disables an unwinder (rather than
  calling the 'disable unwinder' command).  It is not unreasonable to
  think that a user might register multiple unwinders (relating to
  some project) and have one command that disables/enables all the
  related unwinders.  This command might operate by poking the enabled
  attribute of each unwinder object directly, after this commit, this
  would now work correctly.

There's tests for all the changes, and lots of documentation updates
that both cover the new changes, but also further improve (I think)
the general documentation for GDB's Unwinder API.

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

Fix an illegal memory access when an accessing a zer0-lengthverdef table.

  PR 30285
  * elf.c (_bfd_elf_slurp_version_tables): Fail if no version definitions are allocated.

gprofng: Add version symbols to libgprofng.ver

gprofng/ChangeLog
2023-03-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/30089
* libcollector/libgprofng.ver: Add version symbols.
* libcollector/synctrace.c: Fix typo for pthread_mutex_lock.