Given that the disassembler should never abort when decoding
(potentially random) data, assertion statements in the
`get_*reg_qualifier_from_value' function family prove problematic.
Consider the random 32-bit word W, encoded in a data segment and
encountered on execution of `objdump -D <obj_name>'.
If:
(W & ~opcode_mask) == valid instruction
Then before `print_insn_aarch64_word' has a chance to report the
instruction as potentially undefined, an attempt will be made to have
the qualifiers for the instruction's register operands (if any)
decoded. If the relevant bits do not map onto a valid qualifier for
the matched instruction-like word, an abort will be triggered and the
execution of objdump aborted.
As this scenario is perfectly feasible and, in light of the fact that
objdump must successfully decode all sections of a given object file,
it is not appropriate to assert in this family of functions.
Therefore, we add a new pseudo-qualifier `AARCH64_OPND_QLF_ERR' for
handling invalid qualifier-associated values and re-purpose the
assertion conditions in qualifier-retrieving functions to be the
predicate guarding the returning of the calculated qualifier type.
If the predicate fails, we return this new qualifier and allow the
caller to handle the error as appropriate.
As these functions are called either from within
`aarch64_extract_operand' or `do_special_decoding', both of which are
expected to return non-zero values, it suffices that callers return
zero upon encountering `AARCH64_OPND_QLF_ERR'.
Ar present the error presented in the hypothetical scenario has been
encountered in `get_sreg_qualifier_from_value', but the change is made
to the whole family to keep the interface consistent.
Bug: https://sourceware.org/PR31595
The following instructions are added in this patch:
- ADDPT and SUBPT - Add/Subtract checked pointer
- MADDPT and MSUBPT - Multiply Add/Subtract checked pointer
These instructions are part of Checked Pointer Arithmetic extension.
This patch adds assembler and disassembler support for these instructions
with relevant checks. Tests are included as well.
A new flag "+cpa" added to documentation. This flag enables CPA extension.
Regression tested on the aarch64-none-linux-gnu target and no regressions
have been found.
Hi,
Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature with internal names that don't match the actual feature name pauth. The new feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature of Armv8.3-A. Using a different naming for it not based on the formerly "PAC" would create confusion.
Regression tested on aarch64-none-elf, and no regression found.
Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.
Regards,
Matthieu.
From 58b38358b2788939d81f2df7f5fb4c64a31ae06e Mon Sep 17 00:00:00 2001
From: Matthieu Longo <matthieu.longo@arm.com>
Date: Fri, 23 Feb 2024 11:30:40 +0000
Subject: [PATCH] aarch64: rename internals related to PAuth feature to use
pauth in their naming for coherency
Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature
with internal names that don't match the actual feature name pauth. The new
feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature
of Armv8.3-A. Using a different naming for it not based on the formerly "PAC"
would create confusion.
This matches the dependencies in the architecture, in LLVM, and even in the
original Binutils commit message that mistakenly included it only in armv9.4-a.
The particular choices of address indexing, along with their encoding
for RCPC3 instructions lead to the requirement of a new set of operand
descriptions, along with the relevant inserter/extractor set.
That is, for the integer load/stores, there is only a single valid
indexing offset quantity and offset mode is allowed - The value is
always equivalent to the amount of data read/stored by the
operation and the offset is post-indexed for Load-Acquire RCpc, and
pre-indexed with writeback for Store-Release insns.
This indexing quantity/mode pair is selected by the setting of a
single bit in the instruction. To represent these insns, we add the
following operand types:
- AARCH64_OPND_RCPC3_ADDR_OPT_POSTIND
- AARCH64_OPND_RCPC3_ADDR_OPT_PREIND_WB
In the case of loads and stores involving SIMD/FP registers, the
optional offset is encoded as an 8-bit signed immediate, but neither
post-indexing or pre-indexing with writeback is available. This
created the need for an operand type similar to
AARCH64_OPND_ADDR_OFFSET, with the difference that FLD_index should
not be checked.
We thus introduce the AARCH64_OPND_RCPC3_ADDR_OFFSET operand, a
variant of AARCH64_OPND_ADDR_OFFSET, w/o the FLD_index bitfield.
Beyond the need to encode any registers involved in data transfer and
the address base register for load/stores, it is necessary to specify
the data register addressing mode and whether the address register is
to be pre/post-indexed, whereby loads may be post-indexed and stores
pre-indexed with write-back.
The use of a single bit to specify both the indexing mode and indexing
value requires a novel function be written to accommodate this for
address operand insertion in assembly and another for extraction in
disassembly, along with the definition of two insn fields for use with
these instructions.
This therefore defines the following functions:
- aarch64_ins_rcpc3_addr_opt_offset
- aarch64_ins_rcpc3_addr_offset
- aarch64_ext_rcpc3_addr_opt_offset
- aarch64_ext_rcpc3_addr_offset
It extends the `do_special_{encoding|decoding}' functions and defines
two rcpc3 instruction fields:
- FLD_opc2
- FLD_rcpc3_size
The allowed immediate offsets in integer rcpc3 load store instructions
are not encoded explicitly in the instruction itself, being rather
implicitly equivalent to the amount of data loaded/stored by the
instruction.
This leads to the requirement that this quantity be calculated based on
the number of registers involved in the transfer, either as data
source or destination registers and their respective qualifiers.
This is done via `calc_ldst_datasize (const aarch64_opnd_info *opnds)'
implemented here, using a cumulative sum of qualifier sizes preceding
the address operand in the OPNDS operand list argument.
Indicating the presence of the Armv8.2-a feature adding further
support for the Release Consistency Model, the `+rcpc3' architectural
extension flag is added to the list of possible `-march' options in
Binutils, together with the necessary macro for encoding rcpc3
instructions.
Hi,
This patch add support for SVE2.1 instructions ld1q,
ld2q, ld3q and ld4q, st1q, st2q, st3q and st4q.
Regression testing for aarch64-none-elf target and found no regressions.
Ok for binutils-master?
Regards,
Srinath.
Hi,
This patch add support for SVE2.1 instruction dupq, eorqv and extq.
Regression testing for aarch64-none-elf target and found no regressions.
Ok for binutils-master?
Regards,
Srinath.
Hi,
This patch add support for FEAT_SVE2p1 (SVE2.1 Extension) feature
along with +sve2p1 optional flag to enabe this feature.
Also support for following SVE2p1 instructions is added
addqv, andqv, smaxqv, sminqv, umaxqv, uminqv and uminqv.
Regression testing for aarch64-none-elf target and found no regressions.
Ok for binutils-master?
Regards,
Srinath.
Hi,
This patch add support for FEAT_SME2p1 and "movaz" instructions
along with the optional flag +sme2p1.
Following "movaz" instructions are add:
Move and zero two ZA tile slices to vector registers.
Move and zero four ZA tile slices to vector registers.
Regression testing for aarch64-none-elf target and found no regressions.
Ok for binutils-master?
Regards,
Srinath.
Hi,
This patch add support for SVE2.1 and SME2.1 non-widening BFloat16
(FEAT_B16B16) instructions.
Following instructions predicated, unpredicated and indexed
variants are added in this patch.
bfadd, bfclamp, bfmax bfmaxnm, bfmin,bfminnm,
bfmla,bfmls,bfmul and bfsub.
Regression testing for aarch64-none-elf target and found no regressions.
Ok for binutils-master?
Regards,
Srinath.
Additionally, change FEAT_XS tlbi variants to be gated on "+xs" instead of
"+d128". This is an incremental improvement; there are still some FEAT_XS tlbi
variants that are gated incorrectly or missing entirely.
This patch adds support for the new AArch64 system registers that are part of the following extensions:
* FEAT_DEBUGv8p9
* FEAT_PMUv3p9
* FEAT_PMUv3_SS
* FEAT_PMUv3_ICNTR
* FEAT_SEBEP
This patch adds support for FEAT_THE doubleword and quadword instructions.
doubleword insturctions are enabled by "+the" flag whereas quadword
instructions are enabled on passing both "+the and +d128" flags.
Support for following sets of instructions is added in this patch.
Read check write compare and swap doubleword:
(rcwcas, rcwcasa, rcwcasal, rcwcasl)
Read check write compare and swap quadword:
(rcwcasp,rcwcaspa, rcwcaspal, rcwcaspl)
Read check write software compare and swap doubleword:
(rcwscas, rcwscasa, rcwscasal, rcwscasl)
Read check write software compare and swap quadword:
(rcwscasp, rcwscaspa, rcwscaspal, rcwscaspl)
Read check write atomic bit clear on doubleword:
(rcwclr, rcwclra, rcwclral, rcwclrl)
Read check write atomic bit clear on quadword:
(rcwclrp, rcwclrpa, rcwclrpal, rcwclrpl)
Read check write software atomic bit clear on doubleword:
(rcwsclr, rcwsclra, rcwsclral, rcwsclrl)
Read check write software atomic bit clear on quadword:
(rcwsclrp,rcwsclrpa, rcwsclrpal,rcwsclrpl)
Read check write atomic bit set on doubleword:
(rcwset,rcwseta, rcwsetal,rcwsetl)
Read check write atomic bit set on quadword:
(rcwsetp,rcwsetpa,rcwsetpal,rcwsetpl)
Read check write software atomic bit set on doubleword:
(rcwsset,rcwsseta,rcwssetal,rcwssetl)
Read check write software atomic bit set on quadword:
(rcwssetp,rcwssetpa,rcwssetpal,rcwssetpl)
Read check write swap doubleword:
(rcwswp,rcwswpa,rcwswpal,rcwswpl)
Read check write swap quadword:
(rcwswpp,rcwswppa, rcwswppal,rcwswppl)
Read check write software swap doubleword:
(rcwsswp,rcwsswpa,rcwsswpal,rcwsswpl)
Read check write software swap quadword:
(rcwsswpp,rcwsswppa,rcwsswppal,rcwsswppl)
With the addition of 128-bit system registers to the Arm architecture
starting with Armv9.4-a, a mechanism for manipulating their contents
is introduced with the `msrr' and `mrrs' instruction pair.
These move values from one such 128-bit system register into a pair of
contiguous general-purpose registers and vice-versa, as for example:
msrr ttlb0_el1, x0, x1
mrrs x0, x1, ttlb0_el1
This patch adds the necessary support for these instructions, adding
checks for system-register width by defining a new operand type in the
form of `AARCH64_OPND_SYSREG128' and the `aarch64_sys_reg_128bit_p'
predicate, responsible for checking whether the requested system
register table entry is marked as implemented in the 128-bit mode via
the F_REG_128 flag.
The addition of 128-bit page table descriptors and, with it, the
addition of 128-bit system registers for these means that special
"invalidate translation table entry" instructions are needed to cope
with the new 128-bit model. This is introduced with the `tlbpi'
instruction, implemented here.
While CRn and CRm fields in the SYSP instruction are 4-bit wide and
are thus able to accommodate values in the range 0-15, the
specifications for the SYSP instructions limit their ranges to 8-9 for
CRm and 0-7 in the case of CRn.
This led to the need to signal in some way to the operand parser that
a given operand is under special restrictions regarding its use. This
is done via the new `F_OPD_NARROW' flag, indicating a narrowing in the
range of operand values for fields in the instruction tagged with the
flag.
The flag is then used in `parse_operands' when the instruction is
assembled, but needs not be taken into consideration during
disassembly.
Two of the instructions added by the `+d128' architectural extension
add the flexibility to have two optional operands. Prior to the
addition of the `tlbip' and `sysp' instructions, no mnemonic allowed
more than one such optional operand.
With `tlbip' as an example, some TLBIP instruction names do not allow
for any optional operands, while others allow for both to be optional.
In the latter case, it is possible that either the second operand
alone is omitted or both operands are omitted.
Therefore, a considerable degree of flexibility needed to be added to
the way operands were parsed. It was, however, possible to achieve
this with relatively few changes to existing code.
it is noteworthy that opcode flags specifying the optional operand
number are non-orthogonal. For example, we have:
#define F_OPD1_OPT (2 << 12) : 0b10 << 12
#define F_OPD2_OPT (3 << 12) : 0b11 << 12
such that by virtue of the observation that
(F_OPD1_OPT | F_OPD2_OPT) == F_OPD2_OPT
it is impossible to mark both operands 1 and 2 as optional for an
instruction and it is assumed that a maximum of 1 operand can ever be
optional. This is not overly-problematic given that, for optional
pairs, the second optional operand is always found immediately after
the first. Thus, it suffices for us to flag that there is a second
optional operand. With this fact, we can infer its position in the
mnemonic from the position of the first (e.g. if the second operand in
the mnemonic is optional, we know the third is too). We therefore
define the `F_OPD_PAIR_OPT' flag and calculate its position in the
mnemonic from the value encoded by the `F_OPD<n>_OPT' flag.
Another observation is that there is a tight coupling between default
values assigned to the two registers when one (or both) are omitted
from the mnemonic. Namely, if Xt1 has a value of 0x1f (the zero
register is specified), Xt2 defaults to the same value, otherwise Xt2
will be assigned Xt + 1. This meant that where you have default value
validation, in checking the second optional operand's value, it is
also necessary to look at the value assigned to the
previously-processed operand value before deciding its validity. Thus
`process_omitted_operand' needs not only access to its `operand'
argument, but also to the global `inst' struct.
Analysis of the allowed operand values for `sysp' and `tlbip' reveals
a significant departure from the allowed behavior for operand register
pairs (hitherto labeled AARCH64_OPND_PAIRREG) observed for other
insns in this category.
For instructions `casp', `mrrs' and `msrr' the register pair must
always start at an even index and the second register in the pair is
the index + 1. This precludes the use of xzr as the first register,
given it corresponds to register number 31.
This is different in the case of `sysp' and `tlbip', however. These
allow the use of xzr and, where the first operand in the pair is
omitted, this is the default value assigned to it. When this
operand is assigned xzr, it is expected that the second operand will
likewise take on a value of xzr.
These two instructions therefore "break" two rules of register pairs:
* The first of the two registers is odd-numbered.
* The index of the second register is equal to that of the first,
and not n+1.
To allow for this departure from hitherto standard behavior, we
extend the functionality of the assembler by defining an extension of
the AARCH64_OPND_PAIRREG, called AARCH64_OPND_PAIRREG_OR_XZR.
It is used in defining `sysp' and `tlbip' and allows
`operand_general_constraint_met_p' to allow the pair to both take on
the value of xzr.
Given the introduction of the new Armv9.4-a `sysp' insn using the
following syntax:
sysp #<op1>, <Cn>, <Cm>, #<op2>{, <Xt1>, <Xt2>}
and by extension the need to encode 6 assembly operands, extend
Binutils to handle instructions taking 6 operands, up from a previous
maximum of 5.
Indicating the presence of the Armv9.4-a features concerning 128-bit
Page Table Descriptors, 128-bit System Registers and Instructions,
the "+d128" architectural extension flag is added to the list of
possible -march options in Binutils, together with the necessary macro
for encoding d128 instructions.
Adds two new external authors to etc/update-copyright.py to cover
bfd/ax_tls.m4, and adds gprofng to dirs handled automatically, then
updates copyright messages as follows:
1) Update cgen/utils.scm emitted copyrights.
2) Run "etc/update-copyright.py --this-year" with an extra external
author I haven't committed, 'Kalray SA.', to cover gas testsuite
files (which should have their copyright message removed).
3) Build with --enable-maintainer-mode --enable-cgen-maint=yes.
4) Check out */po/*.pot which we don't update frequently.
This patch add supports for FEAT_SPECRES2 "Enhanced speculation
restriction instructions" adding the "cosp" instruction.
This is mandatory v8.9-a/v9.4-a and optional v8.0-a+/v9.0-a+. It is
enabled by the +predres2 march flag.
This patch adds the permission model enhancement and memory
attribute index enhancement features and their corresponding
system registers in AArch64 assembler.
Permission Indirection Extension (FEAT_S1PIE, FEAT_S2PIE)
Permission Overlay Extension (FEAT_S1POE, FEAT_S2POE)
Memory Attribute Index Enhancement (FEAT_AIE)
Extension to Translation Control Registers (FEAT_TCR2)
These features are available by default from Armv9.4-A architecture.
This patch also adds support for:
1. FEAT_RASv2 feature and "ERXGSR_EL1" system register.
RASv2 feature is enabled by passing +rasv2 to -march
(eg: -march=armv8-a+rasv2).
2. FEAT_SCTLR2 and following system registers.
SCTLR2_EL1, SCTLR2_EL12, SCTLR2_EL2 and SCTLR2_EL3.
3. FEAT_FGT2 and following system registers.
HDFGRTR2_EL2, HDFGWTR2_EL2, HFGRTR2_EL2, HFGWTR2_EL2
4. FEAT_PFAR and following system registers.
PFAR_EL1, PFAR_EL2 and PFAR_EL12.
FEAT_RASv2, FEAT_SCTLR2, FEAT_FGT2 and FEAT_PFAR features are by default
enabled from Armv9.4-A architecture.
This patch also adds support for two read only system registers
id_aa64mmfr3_el1 and id_aa64mmfr4_el1, which are available from
Armv8-A Architecture.
This patch adds features to the Statistical Profiling Extension,
identified as FEAT_SPEv1p4, FEAT_SPE_FDS, and FEAT_SPE_CRR, which
are enabled by default from Armv9.4-A.
Also adds support for system register "pmsdsfr_el1".
Enable the `+lse128' feature modifier which, together with new
internal feature flags, enables LSE128 instructions, which are
represented via the new `_LSE128_INSN' macro.
gas/ChangeLog:
* config/tc-aarch64.c (aarch64_features): Add new "lse128"
entry.
include/ChangeLog:
* include/opcode/aarch64.h (enum aarch64_feature_bit): New
AARCH64_FEATURE_LSE128 feature bit.
(enum aarch64_insn_class): New lse128_atomic instruction class.
opcodes/ChangeLog:
* opcodes/aarch64-tbl.h (aarch64_feature_lse128): New.
(LSE128): Likewise.
(_LSE128_INSN): Likewise.
Given the particular encoding of the LSE128 instructions, create the
necessary shared input+output operand register description and
handling in the code to allow for the encoding of the LSE128 128-bit
atomic operations.
gas/ChangeLog:
* config/tc-aarch64.c (parse_operands):
include/ChangeLog:
* opcode/aarch64.h (enum aarch64_opnd):
opcodes/ChangeLog:
* aarch64-opc.c (fields):
(aarch64_print_operand):
* aarch64-opc.h (enum aarch64_field_kind):
* aarch64-tbl.h (AARCH64_OPERANDS):
Add Binutils support for system registers associated with the
Translation Hardening Extension (THE).
In doing so, we also add core feature support for THE, enabling its
associated feature flag and implementing the necessary
feature-checking machinery.
Regression tested on aarch64-linux-gnu, no regressions.
gas/ChangeLog:
* config/tc-aarch64.c (aarch64_features): Add "+the" feature modifier.
* doc/c-aarch64.texi (AArch64 Extensions): Update
documentation for `the' option.
* testsuite/gas/aarch64/sysreg-8.s: Add tests for `the'
associated system registers.
* testsuite/gas/aarch64/sysreg-8.d: Likewise.
include/ChangeLog:
* opcode/aarch64.h (enum aarch64_feature_bit): Add
AARCH64_FEATURE_THE.
opcode/ChangeLog:
* aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Add `the'
system register check support.
* aarch64-sys-regs.def: Add `rcwmask_el1' and `rcwsmask_el1'
* aarch64-tbl.h: Define `THE' preprocessor macro.
This patch adds support for Guarded control stack data synchronization
instruction (GCSB DSYNC). This instruction is allocated to existing
HINT space and uses the HINT number 19 and to match this an entry is
added to the aarch64_hint_options array.
This patch adds for Guarded Control Stack Extension (GCS) extension. GCS feature is
optional from Armv9.4-A architecture and enabled by passing +gcs option to -march
(eg: -march=armv9.4-a+gcs) or using ".arch_extension gcs" directive in the assembly file.
Also this patch adds support for GCS instructions gcspushx, gcspopcx, gcspopx,
gcsss1, gcsss2, gcspushm, gcspopm, gcsstr and gcssttr.
This patch adds support for Check Feature Status Extension (CHK) which
is mandatory from Armv8.0-A. Also this patch supports "chkfeat" instruction
(hint #40).
This patch adds a mechanism for system register name alias detection
to register-matching mechanisms.
A new `F_REG_ALIAS' flag is added to the set of register flags and
used to label which entries in aarch64_sys_regs[] correspond to
aliases (and thus which CPENC values are non-unique in this array).
Where this is used is, for example, in `aarch64_print_operand' where,
in the case of system register decoding, the aarch64_sys_regs[] array
is iterated through until a match in CPENC value is made and the first
match accepted. If insufficient care is given in the ordering of
system registers in this array, the alias is encountered before the
"real" register and used incorrectly as the register name in the
disassembled output.
With this flag and the new `aarch64_sys_reg_alias_p' test, search
candidates corresponding to aliases can be conveniently skipped over.
One concrete example of where this is useful is with the
`trcextinselr0' system register. It was initially placed in the
system register list before `trcextinselr', in contrast to a more
natural alphabetical order.
include/ChangeLog:
* opcode/aarch64.h: add `aarch64_sys_reg_alias_p' prototype.
opcodes/ChangeLog:
* aarch64-opc.c (aarch64_sys_reg_alias_p): New.
(aarch64_print_operand): add aarch64_sys_reg_alias_p check.
(aarch64_sys_regs): Add F_REG_ALIAS flag to "trcextinselr"
entry.
* aarch64-opc.h (F_REG_ALIAS): New.
Following on from the previous patch to make the feature macros take
a word number, this one increases the number of flag words from 1 to 2.
The patch uses some dummy features to push the number of features
over 64. The intention is that these should be reused by real
features rather than kept as-is.
The AArch64 feature-flag code is currently limited to a maximum
of 64 features. This patch reworks it so that the limit can be
increased more easily. The basic idea is:
(1) Turn the ARM_FEATURE_FOO macros into an enum, with the enum
counting bit positions.
(2) Make the feature-list macros take an array index argument
(currently always 0). The macros then return the
aarch64_feature_set contents for that array index.
An N-element array would then be initialised as:
{ MACRO (0), ..., MACRO (N - 1) }
(3) Provide convenience macros for initialising an
aarch64_feature_set for:
- a single feature
- a list of individual features
- an architecture version
- an architecture version + a list of additional features
(2) and (3) use the preprocessor to generate static initialisers.
The main restriction was that uses of the same preprocessor macro
cannot be nested. So if a macro wants to do something for N individual
arguments, it needs to use a chain of N macros to do it. There then
needs to be a way of deriving N, as a preprocessor token suitable for
pasting.
The easiest way of doing that was to precede each list of features
by the number of features in the list. So an aarch64_feature_set
initialiser for three features A, B and C would be written:
AARCH64_FEATURES (3, A, B, C)
This scheme makes it difficult to keep AARCH64_FEATURE_CRYPTO as a
synonym for SHA2+AES, so the patch expands the former to the latter.
Historically, flags and variables relating to architectural revisions
for the A-profile architecture omitted the trailing `A' such that, for
example, assembling for `-march=armv8.4-a' set the `AARCH64_ARCH_V8_4'
flag in the assembler.
This leads to some ambiguity, since Binutils also targets the
R-profile Arm architecture. Therefore, it seems prudent to have
everything associated with the A-profile cores end in `A' and likewise
`R' for the R-profile. Referring back to the example above, the flag
set for `-march=armv8.4-a' is better characterized if labeled
`AARCH64_ARCH_V8_4A'.
The only exception to the rule of appending `A' to variables is found
in the handling of the `AARCH64_FEATURE_V8' macro, as it is the
baseline from which ALL processors derive and should therefore be left
unchanged.
In reflecting the `ARM' architectural nomenclature choices, where we
have `ARM_ARCH_V8A' and `ARM_ARCH_V8R', the choice is made to not have
an underscore separating the numerical revision number and the
A/R-profile indicator suffix. This has meant that renaming of
R-profile related flags and variables was warranted, thus going from
`.*_[vV]8_[rR]' to `.*_[vV]8[rR]'.
Finally, this is more in line with conventions within GCC and adds consistency
across the toolchain.
gas/ChangeLog:
* gas/config/tc-aarch64.c:
(aarch64_cpus): Reference to arch feature macros updated.
(aarch64_archs): Likewise.
include/ChangeLog:
* include/opcode/aarch64.h:
(AARCH64_FEATURE_V8A): Updated name: V8_A -> V8A.
(AARCH64_FEATURE_V8_1A): A-suffix added.
(AARCH64_FEATURE_V8_2A): Likewise.
(AARCH64_FEATURE_V8_3A): Likewise.
(AARCH64_FEATURE_V8_4A): Likewise.
(AARCH64_FEATURE_V8_5A): Likewise.
(AARCH64_FEATURE_V8_6A): Likewise.
(AARCH64_FEATURE_V8_7A): Likewise.
(AARCH64_FEATURE_V8_8A):Likewise.
(AARCH64_FEATURE_V9A): Likewise.
(AARCH64_FEATURE_V8R): Updated name: V8_R -> V8R.
(AARCH64_ARCH_V8A_FEATURES): Updated name: V8_A -> V8A.
(AARCH64_ARCH_V8_1A_FEATURES): A-suffix added.
(AARCH64_ARCH_V8_2A_FEATURES): Likewise.
(AARCH64_ARCH_V8_3A_FEATURES): Likewise.
(AARCH64_ARCH_V8_4A_FEATURES): Likewise.
(AARCH64_ARCH_V8_5A_FEATURES): Likewise.
(AARCH64_ARCH_V8_6A_FEATURES): Likewise.
(AARCH64_ARCH_V8_7A_FEATURES): Likewise.
(AARCH64_ARCH_V8_8A_FEATURES): Likewise.
(AARCH64_ARCH_V9A_FEATURES): Likewise.
(AARCH64_ARCH_V9_1A_FEATURES): Likewise.
(AARCH64_ARCH_V9_2A_FEATURES): Likewise.
(AARCH64_ARCH_V9_3A_FEATURES): Likewise.
(AARCH64_ARCH_V8A): Updated name: V8_A -> V8A.
(AARCH64_ARCH_V8_1A): A-suffix added.
(AARCH64_ARCH_V8_2A): Likewise.
(AARCH64_ARCH_V8_3A): Likewise.
(AARCH64_ARCH_V8_4A): Likewise.
(AARCH64_ARCH_V8_5A): Likewise.
(AARCH64_ARCH_V8_6A): Likewise.
(AARCH64_ARCH_V8_7A): Likewise.
(AARCH64_ARCH_V8_8A): Likewise.
(AARCH64_ARCH_V9A): Likewise.
(AARCH64_ARCH_V9_1A): Likewise.
(AARCH64_ARCH_V9_2A): Likewise.
(AARCH64_ARCH_V9_3A): Likewise.
(AARCH64_ARCH_V8_R): Updated name: V8_R -> V8R.
opcodes/ChangeLog:
* opcodes/aarch64-opc.c (SR_V8A): Updated name: V8_A -> V8A.
(SR_V8_1A): A-suffix added.
(SR_V8_2A): Likewise.
(SR_V8_3A): Likewise.
(SR_V8_4A): Likewise.
(SR_V8_6A): Likewise.
(SR_V8_7A): Likewise.
(SR_V8_8A): Likewise.
(aarch64_sys_regs): Reference to arch feature macros updated.
(aarch64_pstatefields): Reference to arch feature macros updated.
(aarch64_sys_ins_reg_supported_p): Reference to arch feature macros
updated.
* opcodes/aarch64-tbl.h:
(aarch64_feature_v8_2a): a-suffix added.
(aarch64_feature_v8_3a): Likewise.
(aarch64_feature_fp_v8_3a): Likewise.
(aarch64_feature_v8_4a): Likewise.
(aarch64_feature_fp_16_v8_2a): Likewise.
(aarch64_feature_v8_5a): Likewise.
(aarch64_feature_v8_6a): Likewise.
(aarch64_feature_v8_7a): Likewise.
(aarch64_feature_v8r): Updated name: v8_r-> v8r.
(ARMV8R): Updated name: V8_R-> V8R.
(ARMV8_2A): A-suffix added.
(ARMV8_3A): Likewise.
(FP_V8_3A): Likewise.
(ARMV8_4A): Likewise.
(FP_F16_V8_2A): Likewise.
(ARMV8_5): Likewise.
(ARMV8_6A): Likewise.
(ARMV8_6A_SVE): Likewise.
(ARMV8_7A): Likewise.
(V8_2A_INSN): `A' added to macro symbol.
(V8_3A_INSN): Likewise.
(V8_4A_INSN): Likewise.
(FP16_V8_2A_INSN): Likewise.
(V8_5A_INSN): Likewise.
(V8_6A_INSN): Likewise.
(V8_7A_INSN): Likewise.
(V8R_INSN): Updated name: V8_R-> V8R.
