I noticed that I had inadvertently put the "set style warning-prefix"
documentation between the paragraph for "set style sources" and the
paragraph for "show style sources". This patch moves the latter up a
bit to clean this up.
Using explicit pseudo aliases is clearer and more consistent with other
instruction aliases.
This does not change behaviour. For the non-alias instructions
(everything except mov) we already picked the first matching entry for
disassembly by default. For mov we picked the last matching aliased
entry, which remained the original alias since do_misc_decoding doesn't
recognise OP_MOV_PN_PN.
This was an early name for the clrbhb hint instruction. Some software
was written with the old name before it was renamed, so we support it
for assembly but should never use it in disassembly.
This patch has no functional change, because we already pick (by
default) the last matching alias in the opcode table, and clrbhb is
listed later than clearbhb.
Only smov and the second dup variant were previously untested. However,
the only test for umov was a disassembly test with -M no-aliases, and
the first dup variant was only tested in assembly in diagnostic.d with
the non-architectural syntax `dup v0.2d, v1.2d[0]`.
sqabs, abs, not, mvn, sqneg and neg were already tested, and cmeq was
already assembled in an error test (sve-reg-diagnostic.d), but they are
all included here as part of the same encoding group.
Also remove the valid instructions from the test for invalid
instructions - this meant that the instruction was previously being
tested for assembly but not disassembly.
Adjust parsing for AARCH64_OPND_SVE_ADDR_RR{_LSL*} operands to accept
implicit XZR offsets. Add new AARCH64_OPND_SVE_ADDR_RM{_LSL*} operands
to support instructions where an XZR offset is allowed but must be
specified explicitly. This allows the removal of the duplicate opcode
table entries using AARCH64_OPND_SVE_ADDR_R.
The fix for PR22988 in 2018 added a new operand AARCH64_OPND_SVE_ADDR_R
to support implicit XZR offsets, but this fix had several flaws that
meant it accepted several invalid addressing modes:
1. The base register type wasn't properly checked when the optional
register offset was omitted. This meant that
ldff1b {z1.s}, p1/z,[z1.d]
was parsed as if it were
ldff1b z1.d, p1/z, [x1.d, xzr].
2. The explicit offset parsing didn't include a shift type, so the new
operand would incorrectly parse
ldff1h{z0.s}, p0/z, [x0, x0]
as if it were
ldff1h{z0.s}, p0/z, [x0, x0, lsl #1].
3. Regardless of the above correctness issues, support for implicit
offsets should have been added by amending the operands in the existing
opcode table entries, instead of adding new duplicate table entires.
Issue 1 can be fixed by using an "if" instead of an "else if" in
parse_operands, while issue 2 can be fixed by failing when the first
condition is false. This patch applies just these two fixes, leaving
issue 3 to be addressed in a subsequent more invasive patch.
The instructions removed from the test sme-5.d are architecturally
invalid. The new tests cover all of the affected ldff1 variants; the
issue also affected SME ZA ld1*/st1* instructions using the same operand
type.
Thanks to the commit 48558a5e54 ("RISC-V: Allow nested implications for
extensions"), we can write complex extension implications in theory.
However, to actually do that, we need to pass more information to
check_func.
For example, we want to imply 'Zcf' from 'F' if and only if the 'Zce'
extension is also enabled and XLEN is 32. Passing rps is a way to
enable this.
This commit prepares for such complex extension implications.
The augmented hypervisor extension 'sha'[1] is a new profile-defined extension
that captures the full set of features that are mandated to be supported along
with the H extension.
https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc#rva23s64-profile
bfd/ChangeLog:
* elfxx-riscv.c: New extension and implies.
gas/ChangeLog:
* NEWS: New extension.
* testsuite/gas/riscv/imply.d: New test for sha.
* testsuite/gas/riscv/imply.s: Ditto.
* testsuite/gas/riscv/march-help.l: New extension.
This patch support RISC-V Privileged Architecture 1.13 CSRs 'medelegh' and
'hedelegh'. More details between 1.12 and 1.13 see [1].
[1] https://github.com/riscv/riscv-isa-manual/blob/main/src/priv-preface.adoc
Version log: Remove gas/po changes.
bfd/ChangeLog:
* cpu-riscv.c: New option.
* cpu-riscv.h (enum riscv_spec_class): Ditto.
binutils/ChangeLog:
* doc/binutils.texi: New option.
gas/ChangeLog:
* NEWS: Add priv-1.13 support.
* config/tc-riscv.c: New option.
* configure: Ditto.
* configure.ac: Ditto.
* testsuite/gas/riscv/csr-version-1p10.d: New CSR.
* testsuite/gas/riscv/csr-version-1p10.l: New warning.
* testsuite/gas/riscv/csr-version-1p11.d: New CSR.
* testsuite/gas/riscv/csr-version-1p11.l: New warning.
* testsuite/gas/riscv/csr-version-1p12.d: New CSR.
* testsuite/gas/riscv/csr-version-1p12.l: New warning.
* testsuite/gas/riscv/csr.s: New CSR.
* testsuite/gas/riscv/attribute-15.d: New test.
* testsuite/gas/riscv/attribute-16.d: New test.
* testsuite/gas/riscv/csr-version-1p13.d: New test.
* testsuite/gas/riscv/csr-version-1p13.l: New test.
include/ChangeLog:
* opcode/riscv-opc.h (CSR_MEDELEGH): New CSR.
(CSR_HEDELEGH): Ditto.
(DECLARE_CSR): Ditto.
This changes substitute_path_component to use std::string and
std::string_view, simplifying it greatly and removing some manual
memory management.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This moves substitute_path_component out of utils.c. I considered
making a new file for this (still could if someone wants that), but
since the only caller is in auto-load.c, I moved it there instead.
I've also moved the tests into auto-load.c as well. This way
substitute_path_component can be static.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
bin_to_res_menuexitems can be called with random data offsets (and thus
remaining lengths), confusing code that expects 4-byte aligned data.
Prevent an item length adjustment for alignment exceeding the
remaining length and then overflowing.
