Add support for pac_key_[pu]_[0-3](_ns)? register operands for the MRS and MSR
instructions when assembling for Armv8.1-M Mainline, as well as adding the
corresponding support for disassembling instructions that use it.
(cherry picked from commit 1fb5ccd6bf)
For any arm elf target, disable an old piece of code that forced disassembly to
disassemble for 'unknown architecture' which once upon a time meant it would
disassemble ANY arm instruction. This is no longer true with the addition of
Armv8.1-M Mainline, as there are conflicting encodings for different thumb
instructions.
BFD however can detect what architecture the object file was assembled for
using information in the notes section. So if available, we use that,
otherwise we default to the old 'unknown' behaviour.
With the changes above code, a mode changing 'bx lr' assembled for armv4 with
the option --fix-v4bx will result in an object file that is recognized by bfd
as one for the armv4 architecture. The disassembler now disassembles this
encoding as a BX even for Armv4 architectures, but warns the user when
disassembling for Armv4 that this instruction is only valid from Armv4T
onwards.
Remove the unused and wrongfully defined ARM_ARCH_V8A_CRC, and
define and use a ARM_ARCH_V8R_CRC to make sure instructions enabled by
-march=armv8-r+crc are disassembled correctly.
Patch up some of the tests cases, see a brief explanation for each below.
inst.d:
This test checks the assembly & disassembly of basic instructions in armv3m. I
changed the expected behaviour for teqp, cmnp cmpp and testp instructions to
properly print p when disassembling, whereas before, in the 'unknown' case it
would disassemble these as UNPREDICTABLE as they were changed in later
architectures.
nops.d:
Was missing an -march, added one to make sure we were testing the right
behavior of NOP<c> instructions.
unpredictable.d:
Was missing an -march, added armv6 as that reproduced the behaviour being
tested.
This leverages commit ("s390: Simplify (dis)assembly of insn operands
with const bits") to relax the operand constraints of the immediate
operand that contains the constant Z- or T-bit of the following extended
mnemonics:
risbgz, risbgnz, risbhgz, risblgz, rnsbgt, rosbgt, rxsbgt
Previously those instructions were the only ones where the assembler
on s390 restricted the specification of the subject I3/I4 operand values
exactly according to their specification to an unsigned 6- or 5-bit
unsigned integer. For any other instructions the assembler allows to
specify any operand value allowed by the instruction format, regardless
of whether the instruction specification is more restrictive.
Allow to specify the subject I3/I4 operand as unsigned 8-bit integer
with the constant operand bits being ORed during assembly.
Relax the instructions subject significant operand bit masks to only
consider the Z/T-bit as significant, so that the instructions get
disassembled as their *z or *t flavor regardless of whether any reserved
bits are set in addition to the Z/T-bit.
Adapt the rnsbg, rosbg, and rxsbg test cases not to inadvertently set
the T-bit in operand I3, as they otherwise get disassembled as their
rnsbgt, rosbgt, and rxsbgt counterpart.
This aligns GNU Assembler to LLVM Assembler.
opcodes/
* s390-opc.c (U6_18, U5_27, U6_26): Remove.
(INSTR_RIE_RRUUU2, INSTR_RIE_RRUUU3, INSTR_RIE_RRUUU4): Define
as INSTR_RIE_RRUUU while retaining insn fmt mask.
(MASK_RIE_RRUUU2, MASK_RIE_RRUUU3, MASK_RIE_RRUUU4): Treat only
Z/T-bit of I3/I4 operand as significant.
gas/testsuite/
* gas/s390/zarch-z10.s (rnsbg, rosbg, rxsbg): Do not set T-bit.
Reported-by: Dominik Steenken <dost@de.ibm.com>
Suggested-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
(cherry picked from commit b8b60e2d0c)
commit 292676c15a
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Thu Feb 13 13:44:17 2020 -0800
x86: Resolve PLT32 reloc aganst local symbol to section
resolved PLT32 relocation against local symbol to section and
commit 2585b7a5ce
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Sun Jul 19 06:51:19 2020 -0700
x86: Change PLT32 reloc against section to PC32
turned PLT32 relocation against section into PC32 relocation. But these
transformations are valid only for PC-relative relocations. Add fx_pcrel
check for PC-relative relocations when performing these transformations
to keep PLT32 relocation in `movq $foo@PLT, %rax`.
gas/
PR gas/32196
* config/tc-i386.c (tc_i386_fix_adjustable): Return fixP->fx_pcrel
for PLT32 relocations.
(i386_validate_fix): Turn PLT32 relocation into PC32 relocation
only if fixp->fx_pcrel is set.
* testsuite/gas/i386/reloc32.d: Updated.
* testsuite/gas/i386/reloc64.d: Likewise.
* testsuite/gas/i386/reloc32.s: Add PR gas/32196 test.
* testsuite/gas/i386/reloc64.s: Likewise.
ld/
PR gas/32196
* testsuite/ld-x86-64/plt3.s: New file.
* testsuite/ld-x86-64/x86-64.exp: Run plt3.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
(cherry picked from commit 1b714c14e4)
R_X86_64_GOT64 relocation should never be made section relative. Change
tc_i386_fix_adjustable to return 0 for BFD_RELOC_X86_64_GOT64.
gas/
PR gas/32189
* config/tc-i386.c (tc_i386_fix_adjustable): Return 0 for
BFD_RELOC_X86_64_GOT64.
* testsuite/gas/i386/reloc64.d: Updated.
* testsuite/gas/i386/reloc64.s: Add more tests for R_X86_64_GOT64
and R_X86_64_GOTOFF64.
ld/
PR gas/32189
* testsuite/ld-x86-64/x86-64.exp: Run PR gas/32189 test.
* testsuite/ld-x86-64/pr32189.s: New file.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
(cherry picked from commit 8015b1b0c1)
V{BROADCAST,EXTRACT,INSERT}{F,I}128 and VROUND{P,S}{S,D} aren't promoted
to support EGPR in APX spec. Don't promote them out of APX spec. This
commit effectively reverted:
ec3babb8c1 x86/APX: V{BROADCAST,EXTRACT,INSERT}{F,I}128 can also be expressed
5a635f1f59 x86/APX: VROUND{P,S}{S,D} encodings require AVX512{F,VL}
eea4357967 x86/APX: VROUND{P,S}{S,D} can generally be encoded
gas/
PR gas/32171
* testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: Add
V{BROADCAST,EXTRACT,INSERT}{F,I}128 tests with EGPR.
* testsuite/gas/i386/x86-64-apx-evex-promoted.s: Remove
V{BROADCAST,EXTRACT,INSERT}{F,I}128 and VROUND{P,S}{S,D} tests
with EGPR.
* testsuite/gas/i386/x86-64-apx-egpr-inval.l: Updated.
* testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: Likewise.
* testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Likewise.
* testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Likewise.
* testsuite/gas/i386/x86-64-apx-evex-promoted.d: Likewise.
opcodes/
PR gas/32171
* i386-opc.tbl: Remove V{BROADCAST,EXTRACT,INSERT}{F,I}128 and
VROUND{P,S}{S,D} entries with EGPR.
* i386-tbl.h: Regenerated.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
(cherry picked from commit 2963d7d80d)
When VexVVVV handling was re-worked, .insn broke: When an opcode
extension is in use, VexVVVV_DST needs using now, as ModR/M.reg is
already occupied, matching what c8866e3ec5 ("x86: Drop using
extension_opcode to encode vvvv register") did.
While adding (bad) POP2 forms, also slightly adjust existing ones:
No need to use XMM registers, and no need to specify %r8 when really
%rax is meant twice (EVEX.vvvv not really being the culprit there, or
else EVEX.V' would also have needed mentioning).
The first operand is a general register, not an fp register;
the third operand is encoded into RS2, not RS3;
the second operand must match the destination operand.
Add the MT ASE instruction operand types and encodings to the microMIPS
opcode table and enable the assembly of these instructions in GAS from
MIPSr2 onwards. Update the binutils and GAS testsuites accordingly.
References:
"MIPS Architecture for Programmers, Volume IV-f: The MIPS MT Module for
the microMIPS32 Architecture", MIPS Technologies, Inc., Document Number:
MD00768, Revision 1.12, July 16, 2013
Co-Authored-By: Maciej W. Rozycki <macro@redhat.com>
(cherry picked from commit 08e6af1bac)
We print MFTR and MTTR instructions' thread context register operand in
disassembly using the ABI name the register number would correspond to
should the targeted register be a general-purpose register.
However in most cases it is wrong, because general-purpose registers are
only referred when the 'u' and 'sel' operands are 1 and 0 respectively.
And even in these cases the MFGPR and MTGPR aliases take precedence over
the corresponding generic instruction encodings, so you won't see the
valid case to normally trigger.
Conversely decoding the thread context register operand numerically is
always valid, so switch to using it. Adjust test coverage accordingly.
In a subsequent change the scrubber is going to be changed to retain
further whitespace. Test case expectations generally would better not
depend on the specific whitespace treatment by the scrubber, unless of
course a test is specifically about it. Adjust relevant test cases to
permit blanks where those will subsequently appear.
Whitespace in macro arguments either needs quoting / parenthesizing to
reliably not be mistaken for an argument separator, or respective macro
parameters need to be marked as covering all remaining arguments. The
latter appears more appropriate (and far less intrusive) here.
Whitespace in macro arguments either needs quoting / parenthesizing to
reliably not be mistaken for an argument separator, or respective macro
parameters need to be marked as covering all remaining arguments. The
former appears more appropriate here, as the macro parameters already
have ":req".
Whitespace in macro arguments either needs quoting / parenthesizing to
reliably not be mistaken for an argument separator, or respective macro
parameters need to be marked as covering all remaining arguments. The
latter appears more appropriate here.
Whitespace in macro arguments either needs quoting / parenthesizing to
reliably not be mistaken for an argument separator, or respective macro
parameters need to be marked as covering all remaining arguments. The
latter really isn't an option here.
The way the inner macro invocations are written doesn't quite work as
expected (and would actually break subsequently): Due to overly
aggressive removal of whitespace by the scrubber, the incoming \sym and
\offset arguments actually get concatenated; an empty 3rd argument is
being passed to ldrtest2. That just so happened to work as intended; any
use of \offset alone would have exposed the problem. Quote the 3rd
argument, thus retaining enough whitespace to be independent of scrubber
internals.
From especially the checks for the two separator forms it appears to
follow that the construct being touched is about trailing whitespace. In
such a case, considering that for many targets ordinary and line comment
chars overlap, take into account that line comment chars override
ordinary ones in lex[] (logic elsewhere in do_scrub_chars() actually
depends on that ordering, and also accounts for this overriding).
Plus of course IS_NEWLINE() would better also be consulted. Note also
that the DOUBLESLASH_LINE_COMMENTS change should generally have no
effect just yet; it's a prereq for a later change but better fits here.
Leave respective comments as well, and update documentation to correct
which comment form is actually replaced by a single blank (i.e. neither
the ones starting with what {,tc_}comment_chars[] has nor the ones
starting with what line_comment_chars[] has).
Other than documented /**/ comments currently aren't really converted to
a single space, at least not for x86 in its most common configurations.
That'll be fixed subsequently, at which point blanks may appear where so
far none were expected. Furthermore not permitting blanks immediately
inside curly braces wasn't quite logical anyway - such constructs are
composite ones, and hence components ought to have been permitted to be
separated by whitespace from the very beginning.
With this we also don't care anymore whether the scrubber would remove
whitespace around curly braces, so move them from extra_symbol_chars[]
to operand_special_chars[].
Note: The new testcase doesn't actually exercise much (if any) of the
added code. It is being put in place to ensure that subsequently, when
that code actually comes into play, behavior remains the same.
This was missed when support for the insns was added. Just like for
DATA16, in
rex64 neg (%rax)
rex64 neg (%r16)
rex64 {nf} neg (%rax)
it is not logical why the last one shouldn't be permitted. Bypassing
that check requires other adjustments, though, to actually properly
consume (and then squash) the prefix.
Enable full 32-bit and 64-bit multiplication macro verification, by
splitting the 'mul' test into two parts respectively, and run them
across all the compatible architectures.
The multiplication macros expand differently based on the ISA chosen, so
run the 'mul' macro test across compatible architectures, adopting the
'mul-ilocks' test orphaned by commit 23fce1e311 ("MIPS16 intermix test
failure"), <https://sourceware.org/ml/binutils/2009-01/msg00335.html>,
and providing coverage for the expansion variants.
Only run from MIPS III up for now and remove the ISA override from the
source, so that the 64-bit instructions are covered for individual
64-bit architectures.
Enable full 32-bit and 64-bit division macro verification, by splitting
the 'div' test into two parts respectively, and run them across all the
compatible architectures.
The division macros expand differently depending on the ISA selected, so
run the 'div' macro test across compatible architectures, adopting the
'div-ilocks' test orphaned by commit 23fce1e311 ("MIPS16 intermix test
failure"), <https://sourceware.org/ml/binutils/2009-01/msg00335.html>,
and providing coverage for the expansion variants.
Only run from MIPS III up for now and remove the ISA override from the
source, so that the 64-bit instructions are covered for individual
64-bit architectures.
We have an ISA check for the '--trap' command-line option that reports
its incompatibility with the MIPS I architecture. It doesn't prevent
trap instructions from being enabled though, so when attempt is made to
emit one in an expansion of one of the division or multiplication macros
an assertion failure triggers:
.../gas/testsuite/gas/mips/brtr-opt.s: Assembler messages:
.../gas/testsuite/gas/mips/brtr-opt.s:3: Error: trap exception not supported at ISA 1
.../gas/testsuite/gas/mips/brtr-opt.s:9: Warning: divide by zero
.../gas/testsuite/gas/mips/brtr-opt.s:9: Internal error in macro_build at .../gas/config/tc-mips.c:9064.
Please report this bug.
The same assertion failure triggers without an earlier error message
when the initial ISA is compatible with the '--trap', however at the
time an attempt is made to emit a trap instruction from a division or
multiplication macro the ISA has been changed by a '.set' pseudo-op to
an incompatible one.
With the way the situations are mishandled it seems unlikely that anyone
relies on the current semantics and a sane approach is to decide on the
fly according to the currently selected ISA as to whether to emit trap
or breakpoint instructions in the case where '--trap' has been used.
Change our code to do so then and clarify that in the manual, which is
not explicit about how '--trap' is handled with a changing ISA. Mention
the change in NEWS too since it's a applies to a user option.
Add a fully interlocked MIPS IV CPU so that we can have coverage for
MIPS IV instruction sequences with and without instruction separation
required for a HI/LO data anti-dependency.
Similar to the x86_64 testcases, some .s files contain the corresponding
CFI directives. This helps in validating the synthesized CFI by running
those tests with and without the --scfi=experimental command line
option.
GAS issues some diagnostics, enabled by default, with
--scfi=experimental. The diagnostics have been added with an intent to
help user correct inadvertent errors in their hand-written asm. An
error is issued when GAS finds that input asm is not amenable to
accurate CFI synthesis. The existing scfi-diag-*.s tests in the
gas/testsuite/gas/scfi/x86_64 directory test some SCFI diagnostics
already:
- (#1) "Warning: SCFI: Asymetrical register restore"
- (#2) "Error: SCFI: usage of REG_FP as scratch not supported"
- (#3) "Error: SCFI: unsupported stack manipulation pattern"
- (#4) "Error: untraceable control flow for func 'XXX'"
In the newly added aarch64 testsuite, further tests for additional
diagnostics have been added:
- scfi-diag-1.s in this patch highlights an aarch64-specific diagnostic:
(#5) "Warning: SCFI: ignored probable save/restore op with reg offset"
Additionally, some testcases are added to showcase the (currently)
unsupported patterns, e.g., scfi-unsupported-1.s
mov x16, 4384
sub sp, sp, x16
gas/testsuite/:
* gas/scfi/README: Update comment to include aarch64.
* gas/scfi/aarch64/scfi-aarch64.exp: New file.
* gas/scfi/aarch64/ginsn-arith-1.l: New test.
* gas/scfi/aarch64/ginsn-arith-1.s: New test.
* gas/scfi/aarch64/ginsn-cofi-1.l: New test.
* gas/scfi/aarch64/ginsn-cofi-1.s: New test.
* gas/scfi/aarch64/ginsn-ldst-1.l: New test.
* gas/scfi/aarch64/ginsn-ldst-1.s: New test.
* gas/scfi/aarch64/scfi-callee-saved-fp-1.d: New test.
* gas/scfi/aarch64/scfi-callee-saved-fp-1.l: New test.
* gas/scfi/aarch64/scfi-callee-saved-fp-1.s: New test.
* gas/scfi/aarch64/scfi-callee-saved-fp-2.d: New test.
* gas/scfi/aarch64/scfi-callee-saved-fp-2.l: New test.
* gas/scfi/aarch64/scfi-callee-saved-fp-2.s: New test.
* gas/scfi/aarch64/scfi-cb-1.d: New test.
* gas/scfi/aarch64/scfi-cb-1.l: New test.
* gas/scfi/aarch64/scfi-cb-1.s: New test.
* gas/scfi/aarch64/scfi-cfg-1.d: New test.
* gas/scfi/aarch64/scfi-cfg-1.l: New test.
* gas/scfi/aarch64/scfi-cfg-1.s: New test.
* gas/scfi/aarch64/scfi-cfg-2.d: New test.
* gas/scfi/aarch64/scfi-cfg-2.l: New test.
* gas/scfi/aarch64/scfi-cfg-2.s: New test.
* gas/scfi/aarch64/scfi-cfg-3.d: New test.
* gas/scfi/aarch64/scfi-cfg-3.l: New test.
* gas/scfi/aarch64/scfi-cfg-3.s: New test.
* gas/scfi/aarch64/scfi-cfg-4.l: New test.
* gas/scfi/aarch64/scfi-cfg-4.s: New test.
* gas/scfi/aarch64/scfi-cond-br-1.d: New test.
* gas/scfi/aarch64/scfi-cond-br-1.l: New test.
* gas/scfi/aarch64/scfi-cond-br-1.s: New test.
* gas/scfi/aarch64/scfi-diag-1.l: New test.
* gas/scfi/aarch64/scfi-diag-1.s: New test.
* gas/scfi/aarch64/scfi-diag-2.l: New test.
* gas/scfi/aarch64/scfi-diag-2.s: New test.
* gas/scfi/aarch64/scfi-diag-3.l: New test.
* gas/scfi/aarch64/scfi-diag-3.s: New test.
* gas/scfi/aarch64/scfi-ldrp-1.d: New test.
* gas/scfi/aarch64/scfi-ldrp-1.l: New test.
* gas/scfi/aarch64/scfi-ldrp-1.s: New test.
* gas/scfi/aarch64/scfi-ldrp-2.d: New test.
* gas/scfi/aarch64/scfi-ldrp-2.l: New test.
* gas/scfi/aarch64/scfi-ldrp-2.s: New test.
* gas/scfi/aarch64/scfi-ldstnap-1.d: New test.
* gas/scfi/aarch64/scfi-ldstnap-1.l: New test.
* gas/scfi/aarch64/scfi-ldstnap-1.s: New test.
* gas/scfi/aarch64/scfi-strp-1.d: New test.
* gas/scfi/aarch64/scfi-strp-1.l: New test.
* gas/scfi/aarch64/scfi-strp-1.s: New test.
* gas/scfi/aarch64/scfi-strp-2.d: New test.
* gas/scfi/aarch64/scfi-strp-2.l: New test.
* gas/scfi/aarch64/scfi-strp-2.s: New test.
* gas/scfi/aarch64/scfi-unsupported-1.l: New test.
* gas/scfi/aarch64/scfi-unsupported-1.s: New test.
* gas/scfi/aarch64/scfi-unsupported-2.l: New test.
* gas/scfi/aarch64/scfi-unsupported-2.s: New test.
This patch adds support for following sme2.1 zero instructions and
the spec is available here [1].
1. ZERO (single-vector).
2. ZERO (double-vector).
3. ZERO (quad-vector).
The VECTOR GROUP symbols VGx2 and VGx4 are optional for the assembler
for most of the sme and sve instructions. But for few of the sme2.1
zero instruction variants VECTOR GROUP symbols VGx2 and VGx4 are mandatory.
To address this a bit "F_VG_REQ" is introduced in this patch, on setting
F_VG_REQ bit in flags of aarch64_opcode forces the assembler to accept
instruction operand only having VECTOR GROUP symbols.
[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en
This patch adds support for following sme2.1 luti2 and luti4 instructions, spec is
available here [1]
1. LUTI2 (two registers) strided.
2. LUTI2 (four registers) strided.
3. LUTI4 (two registers) strided.
4. LUTI4 (four registers) strided.
[1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en
':' isn't permitted in macro parameter names, hence this separator
construct isn't necessary at the end of labels. Drop its use in such
cases, for being potentially confusing (and hampering readability, even
if only a little).
As indicated in earlier discussion, permitting GOTTPOFF uniformly for
all legacy non-SIMD insns while at the same time restricting to just
certain ADD forms when EVEX-encoded is inconsistent. Make promoted insns
"equal" to their legacy original ones. Doing that adjustment prevents
another inconsistency, too: In
data16 neg (%rax)
data16 neg (%r16)
data16 {nf} neg (%rax)
it is not logical why the last one shouldn't be permitted. Bypassing
that check requires other adjustments, though, to actually properly
consume (and then squash) the data size prefix.
While there also add the missing CMP and TEST cases to the test case
being modified.
While they properly inherited D and C, code processing the reversal of
operands wasn't updated accordingly (and "reversed" operands also
weren't tested anywhere).
MIPSr6 removes condition trap instructions with imm, so we expand
the instruction like "tne $2,IMM" to
li $at,IMM
tne $2,$at
While if IMM is 0, we can use
tne $2,$zero
only.
Three extra octets are now expected with the latest change to base64.s.
They happened to be covered by patterns allowing for zero padding at
the end of the section, but we don't want to allow fewer octets than
expected.
PR 31964
* testsuite/gas/all/base64.d: Adjust.
First input_scrub_next_buffer()'s invocation was wrong, leading to input
only being checked from the last newline till the end of the current
buffer. Correcting the invocation, however, leads to duplicate checking
unless -f (or the #NO_APP equivalent thereof) is in effect. Move the
invocation to input_file_give_next_buffer(), to restrict it accordingly.
Then, when macros contain multi-byte characters, warning about them
again in every expansion isn't useful. Suppress such warnings from
sb_scrub_and_add_sb().
RISC-V Profiles document defines number of "extensions" that indicate
certain platform properties/capabilities just like 'Zkt' extension from the
RISC-V cryptography extensions.
This commit defines 20 platform property/capability extensions as defined
in the RISC-V Profiles documentation.
The only exception: 'Ssstateen' extension is defined separately because it
defines a subset (supervisor/hypervisor view) of the 'Smstateen' extension.
This is based on the ratified version of RISC-V Profiles:
<https://github.com/riscv/riscv-profiles/releases/tag/v1.0>
[Definition]
"Main memory regions":
Main memory regions (in contrast to I/O or vacant memory regions) with
both the cacheability and coherence PMAs.
[New Unprivileged Extensions]
1. 'Ziccif'
"Main memory regions" support instruction fetch and any instruction
fetches of naturally aligned power-of-2 sizes up to min(ILEN, XLEN)
are atomic.
2. 'Ziccrse'
"Main memory regions" provide the eventual success guarantee for
LR/SC sequence (RsrvEventual).
3. 'Ziccamoa'
"Main memory regions" support all currently-defined AMO operations
including swap, logical and arithmetic operations (AMOArithmetic).
4. 'Za64rs'
For LR/SC instructions, reservation sets are contiguous, naturally
aligned and at most 64-bytes in size.
5. 'Za128rs'
Likewise, but reservation sets are at most 128-bytes in size.
6. 'Zicclsm'
Misaligned loads / stores to "main memory regions" are supported.
Those include both regular scalar and vector accesses but does not
include AMOs and other specialized forms of memory accesses.
7. 'Zic64b'
Cache blocks are (exactly) 64-bytes in size and naturally aligned.
[New Privileged Extensions]
1. 'Svbare'
"satp" mode Bare is supported.
2. 'Svade'
Page-fault exceptions are raised when a page is accessed when A bit is
clear, or written when D bit is clear.
3. 'Ssccptr'
"Main memory regions" support hardware page-table reads.
4. 'Sstvecd'
"stvec" mode Direct is supported. When "stvec" mode is Direct,
"stvec.BASE" is capable of holding any valid 4-byte aligned address.
5. 'Sstvala'
"stval" is always written with a nonzero value whenever possible as
specified in the Privileged Architecture documentation
(version 20211203: see section 4.1.9).
6. 'Sscounterenw'
For any "hpmcounter" that is not read-only zero, the corresponding bit
in "scounteren" is writable.
7. 'Ssu64xl'
"sstatus.UXL" is capable of holding the value 0b10
(UXLEN==64 is supported).
8. 'Shcounterenw'
Similar to 'Sscounterenw' but the same rule applies to "hcounteren".
9. 'Shvstvala'
Similar to 'Sstvala' but the same rule applies to "vstval".
10. 'Shtvala'
"htval" is written with the faulting guest physical address as long as
permitted by the ISA (a bit similar to 'Sstvala' and 'Shvstvala').
11. 'Shvstvecd'
Similar to 'Sstvecd' but the same rule applies to "vstvec".
12. 'Shvsatpa'
All translation modes supported in "satp" are also supported in "vsatp".
13. 'Shgatpa'
For each supported virtual memory scheme SvNN supported in "satp", the
corresponding "hgatp" SvNNx4 mode is supported. The "hgatp" mode Bare
is also supported.
[Implications]
(Due to reservation set size constraints)
- 'Za64rs' -> 'Za128rs'
(Due to the fact that a privileged "extension" directly refers a CSR)
- 'Svbare' -> 'Zicsr'
- 'Sstvecd' -> 'Zicsr'
- 'Sstvala' -> 'Zicsr'
- 'Sscounterenw' -> 'Zicsr'
- 'Ssu64xl' -> 'Zicsr'
(Due to the fact that a privileged "extension" indirectly depends on CSRs)
- 'Svade' -> 'Zicsr'
(Due to the fact that a privileged "extension" is a hypervisor property)
- 'Shcounterenw' -> 'H'
- 'Shvstvala' -> 'H'
- 'Shtvala' -> 'H'
- 'Shvstvecd' -> 'H'
- 'Shvsatpa' -> 'H'
- 'Shgatpa' -> 'H'
bfd/
* elfxx-riscv.c (riscv_implicit_subsets): Updated for property
and capability extensions.
(riscv_supported_std_z_ext): Added zic64b, ziccamoa, ziccif, zicclsm,
ziccrse, za64rs and za128rs extensions.
(riscv_supported_std_s_ext): Added shcounterenw, shgatpa, shtvala,
shvsatpa, shvstvala, shvstvecd, ssccptr, sscounterenw, sstvala,
sstvecd, ssu64xlm svade and svbare extensions.
gas/
* testsuite/gas/riscv/imply.d: Updated for property and capability
extensions.
* testsuite/gas/riscv/imply.s: Likewise.
* testsuite/gas/riscv/march-help.l: Likewse.
