aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-03-31gdb: Remove extra if statementAri Hannula1-10/+7
The removed if statement is already checked in the parent if else statement. Co-Authored-By: Christina Schimpe <christina.schimpe@intel.com>
2023-03-31RISC-V: Allocate "various" operand typeTsukasa OI3-25/+71
This commit intends to move operands that require very special handling or operand types that are so minor (e.g. only useful on a few instructions) under "W". I also intend this "W" to be "temporary" operand storage until we can find good two character (or less) operand type. In this commit, prefetch offset operand "f" for 'Zicbop' extension is moved to "Wif" because of its special handling (and allocating single character "f" for this operand type seemed too much). Current expected allocation guideline is as follows: 1. 'W' 2. The most closely related single-letter extension in lowercase (strongly recommended but not mandatory) 3. Identify operand type The author currently plans to allocate following three-character operand types (for operands including instructions from unratified extensions). 1. "Wif" ('Zicbop': fetch offset) 2. "Wfv" (unratified 'Zfa': value operand from FLI.[HSDQ] instructions) 3. "Wfm" / "WfM" 'Zfh', 'F', 'D', 'Q': rounding modes "m" with special handling solely for widening conversion instructions. gas/ChangeLog: * config/tc-riscv.c (validate_riscv_insn, riscv_ip): Move from "f" to "Wif". opcodes/ChangeLog: * riscv-dis.c (print_insn_args): Move from "f" to "Wif". * riscv-opc.c (riscv_opcodes): Reflect new operand type.
2023-03-31x86: convert testcases to use .insnJan Beulich39-523/+346
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.
2023-03-31x86: document .insnJan Beulich2-0/+133
... and mention its introduction in NEWS.
2023-03-31x86: handle immediate operands for .insnJan Beulich6-4/+182
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.
2023-03-31x86: allow for multiple immediates in output_disp()Jan Beulich1-5/+5
.insn isn't going to have a constraint of only a single immediate when, in particular, RIP-relative addressing is used.
2023-03-31x86: handle EVEX Disp8 for .insnJan Beulich5-1/+149
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.
2023-03-31x86: process instruction operands for .insnJan Beulich6-21/+432
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.
2023-03-31x86: parse special opcode modifiers for .insnJan Beulich1-1/+38
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.
2023-03-31x86: parse VEX and alike specifiers for .insnJan Beulich6-6/+252
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.
2023-03-31x86: introduce .insn directiveJan Beulich9-10/+218
For starters this deals with only very basic constructs.
2023-03-31Arm64/ELF: accept relocations against STN_UNDEFJan Beulich1-1/+5
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.
2023-03-31Automatic date update in version.inGDB Administrator1-1/+1
2023-03-30PR gdb/30219: Clear sync_quit_force_run in quit_forceKevin Buettner2-0/+9
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>
2023-03-30aarch64: Remove stray reglist variableRichard Sandiford1-1/+1
Sorry for not catching this during testing. I was using a host compiler that predated the switch to -fno-common.
2023-03-30aarch64: Add the RPRFM instructionRichard Sandiford14-886/+1113
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.
2023-03-30aarch64: Add the SVE FCLAMP instructionRichard Sandiford10-760/+873
2023-03-30aarch64: Add new SVE shift instructionsRichard Sandiford9-873/+1006
This patch adds the new SVE SQRSHRN, SQRSHRUN and UQRSHRN instructions.
2023-03-30aarch64: Add new SVE saturating conversion instructionsRichard Sandiford9-752/+881
This patch adds the SVE SQCVTN, SQCVTUN and UQCVTN instructions, which are available when FEAT_SME2 is implemented.
2023-03-30aarch64: Add new SVE dot-product instructionsRichard Sandiford16-854/+1111
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.
2023-03-30aarch64: Add the SVE BFMLSL instructionsRichard Sandiford9-742/+936
This patch adds the SVE BFMLSLB and BFMLSLT instructions, which are available when FEAT_SME2 is implemented.
2023-03-30aarch64: Add the SME2 UZP and ZIP instructionsRichard Sandiford9-338/+790
This patch adds UZP and ZIP, which combine UZP{1,2} and ZIP{1,2} into single instructions.
2023-03-30aarch64: Add the SME2 UNPK instructionsRichard Sandiford9-709/+945
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.
2023-03-30aarch64: Add the SME2 shift instructionsRichard Sandiford25-508/+1066
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.
2023-03-30aarch64: Add the SME2 saturating conversion instructionsRichard Sandiford21-468/+921
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.
2023-03-30aarch64: Add the SME2 FP<->FP conversion instructionsRichard Sandiford9-948/+1102
This patch adds the BFCVT{,N} and FCVT{,N} instructions, which narrow a pair of .S registers to a single .H register.
2023-03-30aarch64: Add the SME2 FP<->int conversion instructionsRichard Sandiford9-749/+1190
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.
2023-03-30aarch64: Add the SME2 CLAMP instructionsRichard Sandiford9-820/+1299
FCLAMP, SCLAMP and UCLAMP share the same format, although FCLAMP doesn't have a .B form.
2023-03-30aarch64: Add the SME2 MOPA and MOPS instructionsRichard Sandiford9-717/+966
[BSU]MOP[AS] share the same format.
2023-03-30aarch64: Add the SME2 vertical dot-product instructionsRichard Sandiford30-669/+1345
There are three instruction formats here: - BFVDOT + FVDOT - SVDOT + UVDOT - SUVDOT + USVDOT There are also 64-bit forms of SVDOT and UVDOT.
2023-03-30aarch64: Add the SME2 dot-product instructionsRichard Sandiford30-753/+3708
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.
2023-03-30aarch64: Add the SME2 MLALL and MLSLL instructionsRichard Sandiford29-851/+3921
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).
2023-03-30aarch64: Add the SME2 MLAL and MLSL instructionsRichard Sandiford17-665/+3573
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.
2023-03-30aarch64: Add the SME2 FMLA and FMLS instructionsRichard Sandiford22-529/+1884
2023-03-30aarch64: Add the SME2 maximum/minimum instructionsRichard Sandiford13-445/+3198
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.
2023-03-30aarch64: Add the SME2 ADD and SUB instructionsRichard Sandiford31-488/+2177
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}'
2023-03-30aarch64: Add the SME2 ZT0 instructionsRichard Sandiford20-409/+1443
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.
2023-03-30aarch64: Add the SME2 predicate-related instructionsRichard Sandiford37-845/+3961
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.
2023-03-30aarch64: Add the SME2 multivector LD1 and ST1 instructionsRichard Sandiford40-448/+8895
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.
2023-03-30aarch64: Add the SME2 MOVA instructionsRichard Sandiford21-314/+2282
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.
2023-03-30aarch64: Add support for predicate-as-counter registersRichard Sandiford22-1600/+1983
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.
2023-03-30aarch64; Add support for vector offset rangesRichard Sandiford13-13/+151
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.
2023-03-30aarch64: Add support for vgx2 and vgx4Richard Sandiford15-9/+173
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.
2023-03-30aarch64: Add _off4 suffix to AARCH64_OPND_SME_ZA_arrayRichard Sandiford5-11/+11
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.
2023-03-30aarch64: Add a _10 suffix to FLD_imm3Richard Sandiford6-8/+8
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.
2023-03-30aarch64: Add +sme2Richard Sandiford4-0/+7
This patch adds bare-bones support for +sme2. Later patches fill in the rest.
2023-03-30aarch64: Prefer register ranges & support wrappingRichard Sandiford12-983/+1039
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.
2023-03-30aarch64: Add support for strided register listsRichard Sandiford7-62/+135
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.
2023-03-30aarch64: Sort fields alphanumericallyRichard Sandiford2-163/+164
This patch just sorts the field enum alphanumerically, which makes it easier to see if a particular field has already been defined.
2023-03-30aarch64: Resync field namesRichard Sandiford1-7/+7
This patch just makes the comments in aarch64-opc.c:fields match the names of the associated FLD_* enum.