Many instructions have constraints on the range of registers they can
use. This means that some bits in the register number are fixed, and
therefore aren't mapped to a field in the instruction encoding.
Currently we use various adhoc rules to handle these fixed bits, but
this doesn't handle all cases and we often have to write new code to
support new combinations of permitted registers.
This patch allows these constant bits to instead be specified in the
same structure used to represent instruction fields. Uses of the new
constant fields will be introduced in subsequent patches.
This patch adds support for hypervisor control registers on AArch64,
available via the Generic Interrupt Controller v5 feature, and enabled
via the +gcie flag.
- ich_apr_el2
- ich_contextr_el2
- ich_hfgitr_el2
- ich_hfgrtr_el2
- ich_hfgwtr_el2
- ich_hppir_el2 (RO)
- ich_ppi_activer[0,1]_el2
- ich_ppi_dvir[0,1]_el2
- ich_ppi_enabler[0,1]_el2
- ich_ppi_pendr[0,1]_el2
- ich_ppi_priorityr[0,15]_el2
- ich_vctlr_el2
- ich_vmcr_el2
This patch adds support for PPI registers on AArch64, available via the
Generic Interrupt Controller v5 feature, and enabled via the +gcie flag.
- icc_ppi_cactiver[0,1]_el1
- icc_ppi_cpendr[0,1]_el1
- icc_ppi_enabler[0,1]_el1
- icc_ppi_hmr[0,1]_el1 (RO)
- icc_ppi_priorityr[0,15]_el1
- icc_ppi_sactiver[0,1]_el1
- icc_ppi_spendr[0,1]_el1
Also, the new system register 'icc_ppi_priorityr8_el1' clashed with the
encoding of 's3_0_c12_c15_0' used in a test for the generic syntax of
system registers using mrs and msr.
This patch replaces 's3_0_c12_c15_0' in the test by an unused encoding:
s3_7_c0_c15_0.
This patch adds support for 13 new AArch64 system registers for the CPU
interface, which are enabled on using Generic Interrupt Controller v5
(+gcie flag) feature:
- 7 R/W registers: ICC_APR_EL1, ICC_APR_EL3, ICC_CR0_EL1, ICC_CR0_EL3
ICC_ICSR_EL1, ICC_PCR_EL1, ICC_PCR_EL3.
- 6 RO registers: ICC_DOMHPPIR_EL3, ICC_HAPR_EL1, ICC_HPPIR_EL1,
ICC_HPPIR_EL3, ICC_IAFFIDR_EL1, ICC_IDR0_EL1.
Note: the already-existing ID_AA64PFR2_EL1 register is required by the
GICv5 feature.
Add new instructions from the Generic Interrupt Controller, GICv5,
extension. These instructions are aliases to system instructions and are
the following:
* gic <operation>, <reg>
* gicr <reg>, <operation>
* gsb <operation>
Generic Interrupt Controller v5, GICv5, adds new system registers
and system instructions. These are enabled with the +gcie flag, where
gcie stands for GICv5 (Generic Interrupt Controller) CPU Interrupt
Extension.
This avoids a gcc-14.2 bug reporting an "error: null destination
pointer" on an sprintf buffer that is not NULL. Don't ask me why this
happens to work.
* msp430-dis.c (msp430_singleoperand): Don't overprint op or
comm for extended_dst.
This is the binutils fix for PR 33384. Here we are assuming that no
const char* comma-separated option strings are passed in to
disassemble_info.disassembler_options. That is true for current usage
in gdb and binutils. In fact, there is only one place that passes a
string in read-only memory, gdb/tdep-i386.c:disassembly_flavor, and
that one is a single option.
include/
* dis-asm.h (struct disassemble_info): Comment.
(disassembler_options_cmp, next_disassembler_option),
(FOR_EACH_DISASSEMBLER_OPTION): Delete.
(for_each_disassembler_option): Declare.
opcodes/
* disassemble.c (disassembler_options_cmp): Delete.
(for_each_disassembler_option): New function.
* arc-dis.c (parse_option): Replace disassembler_options_cmp
with strcmp.
(parse_cpu_option): Likewise.
(parse_disassembler_options): Replace FOR_EACH_DISASSEMBLER_OPTION
with for_each_disassembler_option, and extract loop body to..
(arc_parse_option): ..this new function.
* arm-dis.c (parse_arm_disassembler_options): Delete, extracting
loop body to..
(arm_parse_option): ..this new function.
(print_insn): Use for_each_disassembler_option.
* csky-dis.c (parse_csky_dis_options): Delete, extracting loop
body to..
(parse_csky_option): ..this new function.
(print_insn_csky): Use for_each_disassembler_option.
* nfp-dis.c (parse_disassembler_options): Replace
FOR_EACH_DISASSEMBLER_OPTION with for_each_disassembler_option,
and extract loop body to..
(nfp_parse_option): ..this new function. Use opcodes_error_handler
here rather than info->fprintf_func to print error.
* ppc-dis.c (ppc_parse_cpu): Replace disassembler_options_cmp
with strcmp.
(struct ppc_parse_data): New.
(powerpc_init_dialect): Adjust to use new struct. Replace
FOR_EACH_DISASSEMBLER_OPTION with for_each_disassembler_option,
and extract loop body to..
(ppc_parse_option): ..this new function.
Historically we have been inconsistent and overly restrictive in our
choice of features to gate system register accesses. (Originally this
gating was always applied, but now it is disabled unless the
--menable-sysreg-checking option is specified).
This patch updates these constraints, following the principle that we
should only reject a system register access if it requires some
architecture feature or version whose corresponding command line
extension has not been enabled.
The most common change in this patch concerns system registers that
were:
- part of a feature FEAT_X with no corresponding command line extension;
- introduced in a newer architecture version ArmvX.Z;
- permitted to be implemented from an earlier version ArmvX.Y.
Previously these system registers tended to be gated on ArmvX.Z or left
ungated, but following the above principle they are now gated on ArmvX.Y
instead.
Most support for CSRE was removed from Binutils in 2021 after it was
removed from the architecture. This patch removes the remaining system
registers and test files.
Remove all test cases that expect spmzr_el0 to be readable, and remove
some redundant default macro values from armv9_5-a-sysregs.s while we're
there.
Add a read of spmzr_el0 to sysreg-diagnostics.s. This turns out to be
the first test for the "reading from a write-only register" note.
Also remove the recently added -menable-sysreg-checking option from this
test, both to simplify the addition of spmzr_el0 to the test, and to
verify that read/write diagnostics don't depend on that option.
The flag is unnecessary, because we can just unconditionally check the
features field every time. Having the information duplicated in two
separate fields makes it harder to maintain, particularly in the context
of the upcoming regating patch.
The reg_flags parameter of aarch64_sys_ins_reg_supported_p is now
unused, so remove that as well.
The opcode D6 has been officially reserved as a single-byte permanent
undefined (#UD) opcode in 64-bit mode with the mnemonic UDB. This is
already the behavior of all known 64-bit implementations; this is thus
merely an official statement of forward compatibility and the
assignment of a mnemonic.
This will be documented in the next version of the Intel Software
Developer's Manual; in the meantime I DO speak officially for Intel on
this issue.
The x86 Advisory Council has ratified this decision, and so it is
expected to be honored across vendors, but I obviously cannot make any
official statement on any other vendor's behalf.
I am covered by the Intel-FSF copyright assignment for binutils.
Signed-off-by: H. Peter Anvin (Intel) <hpa@zytor.com>
I made a stupid mistake in the commit 28520d7, allow to assemble slli/srli/srai
with 0 immediate to hint c.slli/c.srli/c.srai. These hints will be regared as
illegal instruction for gdb and qemu, so at least I got following gcc testcases
failed,
=== g++: Unexpected fails for rv64gc lp64d medlow ===
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-6.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-p-6.c -O0 execution test
=== gfortran: Unexpected fails for rv64gc lp64d medlow ===
FAIL: gfortran.dg/leadz_trailz_2.f90 -O0 execution test
=== gcc: Unexpected fails for rv64gc lp64d medlow ===
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-6.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-p-17.c -O0 execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-p-6.c -O0 execution test
So we should just allow c.slli/c.srli/c.srai with zero immediate as hints, but
don't allow slli/srli/srai with zero immediate.
gas/
PR 33216
* testsuite/gas/riscv/c-zero-imm.d: Only allow c.slli/c.srli/c.srai
with zero immediate as hints, but don't allow slli/srli/srai with
zero immediate.
* testsuite/gas/riscv/c-zero-imm.s: Likewise.
opcodes/
PR 33216
* riscv-opc.c (match_slli_as_c_slli): Added back.
(match_srxi_as_c_srxi): Likewise.
(riscv_opcodes): Only allow c.slli/c.srli/c.srai with zero immediate
as hints, but don't allow slli/srli/srai with zero immediate.
The original patch,
e6f372ba66
Since recently c.slli64, c.srai64, and c.srli64 have been removed from the
riscv-isa-manual, c.slli, c.srli, and c.srai with 0 immediate are now listed
as hints,
https://github.com/riscv/riscv-isa-manual/pull/1942 and https://github.com/riscv/riscv-isa-manual/pull/2093
So allow c.slli, c.srli, and c.srai with 0 immediate as a hint. Also allow to
assemble slli, srli and srai with 0 immediate to hint c.slli, c.srli and c.srai
when rvc is enabled. The c.slli64, c.srai64, and c.srli64 should be kept as
aliases, so dis-assembler should disassemble to c.slli, c.srli, and c.srai with
0 immediate.
Passed rv32/64-elf/linux binutils testcases.
gas/
PR 33216
* testsuite/gas/riscv/c-zero-imm.d: Updated since allow c.slli64,
c.srai64, and c.srli64 with 0 immediate as a hint.
* testsuite/gas/riscv/c-zero-imm.s: Likewise.
* testsuite/gas/riscv/zca.d: Likewise.
opcodes/
PR 33216
* riscv-opc.c (riscv_opcodes): Updated since allow c.slli64, c.srai64,
and c.srli64 with 0 immediate as a hint.
With the tables no longer being part of libopcodes (but rather being
compiled directly into gas), this table doesn't need exposing anymore.
The declaration cannot be avoided, though, as the first use of the
array sits ahead of its definition (in i386-tbl.h).
There's no reason to allow the array to be modifiable. In fact the
compiler is able to infer this, placing the array in .data.rel.ro, but
let's make it explicit.
Merge them into a single array of struct type. There's further no reason
to have the compiler materialize such objects on the stack. And there's
also no reason to allow the array(s) to be modifiable. Finally, given
how short the strings are, there's little point using more space to
store pointers to them (on 64-bit hosts; the situation is a little
better on 32-bit ones).
While there also correct indentation in adjacent code, and avoid open-
coding ARRAY_SIZE().
The indices into the auto-generated tables for opcodes are relatively
unstable. Adding a new opcode can permute the code significantly.
But most of this churn is down to changes in the index values. To
minimize this use enumerated constants. While the index values
change, the enumeration names will need to do so far less often, so
most of the changes in the generated code become localized to the
addition (occasionally removal) of opcodes. This change also makes
the state-change comments unnecessary. The enumeration names contain
the same information (and more), so these are simply deleted.
The enumeration values are placed in a new header file, aarch64-tbl-2.h,
so aarch64-gen gains a new option to build this header and the Makefile
rules are adjusted accordingly.
The generated aarch64 operand tables use index values into an array. But if
the table of operands is modified by inserting a new operand into the middle
of the table, *all* the index values can change, leading to a lot of
churn in the generated output.
include/opcode/aarch64.h already provides an enumeration for the operands,
so make use of that instead of printing out the raw index values.
This field was misnamed in aarch64_opcode_table. It previously didn't
matter too much as the name field only appeared in dumps. But it
doesn't match the enum in include/opcode/aarch64.h and we will shortly
start to rely on that.
In ISE058, the AVX10.2 imply is removed from AMX-AVX512. This
leads to re-consideration on the imply for AMX-AVX512.
Since it is using zmm register and using zmm register only, we
need to at least imply AVX512F. AVX512VL is not needed since it
is not using xmm/ymms.
On the other hand, if we imply AVX10.1 for AMX-AVX512, disabling
avx10.1 will lead to disabling AMX-AVX512. This would be a surprise
for users.
Based on the two reasons above, the patch is decoupling AMX-AVX512
from AVX10.2 and imply AVX512F.
opcodes/ChangeLog:
* i386-gen.c: Imply AVX512F instead of AVX10.2.
* i386-init.h: Regenerated.
By default, NIL qualifiers are treated as matching any qualifier when
checking operand constraints. For many SVE instructions, this would
allow operands with missing type suffixes to be assembled as if they had
any explicit type specified. To prevent this, the F_STRICT flag is used
to specify that NIL qualifiers should match only NIL qualifiers.
Unfortunately, several SVE instructions incorrectly omitted this
F_STRICT flag. The bug has existed in the *MATMUL_SVE* macros since
they were added in 2019. The macro LUT_SVE2_INSN was added last year,
and the other incorrect macros are new in this release.
LUTv2_SME2_INSN and LUTv2_SME2p1_INSN were not actually broken, because
we reject untyped vector lists already during parsing. However, I have
added the F_STRICT flag here anyway, since this is more consistent and
would be more robust if those operands start accepting untyped vector
lists in the future. The new luti4 tests are the only ones that were
already rejected before this change.
BFLOAT16_SVE_INSN has been unused since it was originally added, so I
just deleted the macro.
The SVE LUT instructions were using the lut instruction class, which
has special handling only for SIMD operands, and isn't recognised by
aarch64_decode_variant_using_iclass (which sets the qualifiers during
decode for most SVE instructions). To prevent these instructions
failing to disassemble, I changed their instruction class to sve_misc.
Many instructions explicitly specified SVE/SVE2/SME/SME2 as a required
feature when it was already implied by another required feature (at
least while the SME->SVE2 implication is retained internally). These
redundant features were used to determine both the valid symbol names
for immediate operands, and the choice of error message for invalid
movprfx sequences. Those two scenarios no longer use architecture
features, so the redundant features are now truly redundant.
Previously the choice of error message for an invalid movprfx sequence
used the architecture requirements to determine whether an instruction
was an SVE instruction or not. This meant specifying SVE or SVE2 as an
explicit architecture requirement for all SVE instructions, even when
this was already implied by another feature. As more architecture
features are added and with the partial removal of the SME->SVE2
dependency, these extra feature requirements were getting messier and
easier to forget.
Instead, we now look at the operand types. If there is an SVE_REG,
SVE_REGLIST or PRED_REG operand, then we treat the instruction as an SVE
instruction. This does change behaviour slightly, but it only affects
the choice of error message and the new choice should be a bit more
consistent.
There is one testsuite update required, because Ezra's SVE_AES2 patch
temporarily broke classification of FEAT_SVE_AES instructions. This
patch restores the original behaviour.
