Having templates with a suffix explicitly present has always been
quirky. Introduce a 2nd matching pass in case the 1st one couldn't find
a suitable template _and_ didn't itself already need to trim off a
suffix to find a match at all. This requires error reporting adjustments
(albeit luckily fewer than I was afraid might be necessary), as errors
previously reported during matching now need deferring until after the
2nd pass (because, obviously, we must not emit any error if the 2nd pass
succeeds). While also related to PR gas/29524, it was requested that
move-with-sign-extend be left as broken as it always was.
PR gas/29525
Note that with the dropped CMPSD and MOVSD Intel Syntax string insn
templates taking operands, mixed IsString/non-IsString template groups
(with memory operands) cannot occur anymore. With that
maybe_adjust_templates() becomes unnecessary (and is hence being
removed).
PR gas/29526
Note further that while the additions to the intel16 testcase aren't
really proper Intel syntax, we've been permitting all of those except
for the MOVD variant. The test therefore is to avoid re-introducing such
an inconsistency.
This reverts the disassembler parts of 859aa2c86d ("x86: Allow 16-bit
register source for LAR and LSL"), adjusting testcases as necessary.
That change was itself a partial revert of c9f5b96bda ("x86: correct
handling of LAR and LSL"), without actually saying so. While the earlier
commit was properly agreed upon, the partial revert was not, and hence
should not have been committed. This is even more so that the revert
part of that change wasn't even necessary to address PR gas/29844.
Speed up gas startup by avoiding runtime allocation of the instances of
type "templates". At the same time cut the memory requirement to just
very little over half (not even accounting for any overhead
notes_alloc() may incur) by reusing the "end" slot of a preceding entry
for the "start" slot of the subsequent one.
Now that the table is local to gas, ARRAY_SIZE() can be used to
determine the end of the table. Re-arrange the processing loop in
md_begin() accordingly, at the same time folding the two calls to
notes_alloc() into just one.
Remove the now empty i386-opc.c. To compensate, tie table generation in
opcodes/ to the building of i386-dis.o, despite the file not really
depending on the generated data.
Unlike many other architectures, x86 does not share an opcode table
between assembly and disassembly. Any consumer of libopcodes would only
ever access one of the two. Since gas is the only consumer of the
assembly data, move it there. While doing so mark respective entities
"static" in i386-gen (we may want to do away with i386_regtab_size
altogether).
This also shrinks the number of relocations to be processed for
libopcodes.so by about 30%.
For all the xh_mode usage in table, they are all using %XH, which will
print "{bad}" while EVEX.W=1. This makes this vex.w check unnecessary.
opcodes/ChangeLog:
* i386-dis.c (OP_E_memory): Remove vex.w check for xh_mode.
This commit adds disassembler styling support for MIPS. After this
commit objdump and GDB will style disassembler output.
This is a pretty straight forward change, we switch to use the
disassemble_info::fprintf_styled_func callback, and pass an
appropriate style through as needed. No additional tricks were
needed (compared to say i386, or ARM).
Tested by running all of the objdump commands used by the gas
testsuite and manually inspecting the styled output, everything looks
reasonable, though I'm not a MIPS expert, so it is possible that I've
missed some corner cases. Worst case though is that something will be
styled incorrectly, the actual content should be unchanged.
All the gas, ld, and binutils tests still pass for me.
While working on disassembler styling for MIPS, I noticed that
undefined instructions are printed by the disassembler as raw number
with no assembler directive prefix (e.g. without .word or .short).
I think adding something like .word, or .short, helps to make it
clearer the size of the value that is being displayed, and is inline
with what many of the other libopcode disassemblers do.
In this commit I've added the .word and .short directives, and updated
all the tests that I spotted that failed as a result.
Since LAR and LSL only access 16 bits of the source operand, regardless
of operand size, allow 16-bit register source for LAR and LSL, and always
disassemble LAR and LSL with 16-bit source operand.
gas/
PR gas/29844
* testsuite/gas/i386/i386.s: Add tests for LAR and LSL.
* testsuite/gas/i386/x86_64.s: Likewise.
* testsuite/gas/i386/intelbad.s: Remove "lar/lsl eax, ax".
* testsuite/gas/i386/i386-intel.d: Updated.
* testsuite/gas/i386/i386.d: Likewise.
* testsuite/gas/i386/intel-intel.d: Likewise.
* testsuite/gas/i386/intel.d: Likewise.
* testsuite/gas/i386/intelbad.l: Likewise.
* testsuite/gas/i386/x86_64-intel.d: Likewise.
* testsuite/gas/i386/x86_64.d: Likewise.
opcodes/
PR gas/29844
* i386-dis.c (MOD_0F02): Removed.
(MOD_0F03): Likewise.
(dis386_twobyte): Restore larS and lslS.
(mod_table): Remove MOD_0F02 and MOD_0F03.
* i386-opc.tbl: Allow 16-bit register source for LAR and LSL.
* i386-tbl.h: Regenerated.
With the general use of C99 there's no need anymore to have i386-gen
produce these. For more frequently used ones introduce local #define-s,
while others are simply spelled out directly. While doing this move
some static constants into more narrow scopes.
Note that as a "side effect" this corrects type_names[]'es imm8s entry.
Leverage the C (commutative) attribute to also reduce the number of XCHG
and TEST templates we have. This way the reg <-> r/m (and reg <-> reg for
XCHG) forms can also be folded into a single template each, utilizing D.
i386-init.h and i386-tbl.h are generated files. There is nothing to
translate. Remove them from HFILES (POTFILES).
* Makefile.am (HFILES): Remove i386-init.h and i386-tbl.h.
* Makefile.in: Regenerated.
* po/POTFILES.in: Likewise.
With the removal of its use for FPU insns the suffix is now finally
properly misnamed. Drop its use altogether, replacing it by a separate
boolean instead.
As a comment near the top of match_template() already says: We really
only need this pseudo-suffix for far branch handling. Stop "deriving" it
for floating point insns. (Don't bother renaming the now properly
misnamed LONG_DOUBLE_MNEM_SUFFIX, to e.g. FAR_BRANCH_SUFFIX - it's going
to disappear anyway.)
At the very least a comment in process_operands() is stale. Beyond that
there are effectively two options:
1) It is possible that FADDP and FMULP were mistakenly not marked as
being in need of dealing with the compiler anomaly, and hence the
respective templates weren't removed at the time when they should
have been.
2) It is also possible that there are indeed uses known beyond compiler
generated output for these two commutative opcodes, and hence the
templates need to stay.
To be on the safe side assume 2: Update the comment and fold the
templates into their "normal" ones (utilizing D), adjusting consuming
code accordingly.
For FMULP also add a comment paralleling a similar one FADDP has.
There are just 4 templates using it, which can be easily identified by
other means, as D is set only on a very limited number of FPU templates.
Also move the respective conditional out of the code path taken by all
"reverse match" insns (it probably should have been this way already
before, to avoid the one conditional in the common case).
With this the templates which had FloatR dropped no longer differ from
their AT&T syntax + mnemonic counterparts - the only difference is now
which of the two would be recognized. For this, however, we don't need
two templates - we can simply arrange the condition for setting
Opcode_FloatR accordingly.
Commit bb996692bd ("RISC-V/gas: allow generating up to 176-bit
instructions with .insn") tried to start supporting long instructions but
it was insufficient.
On the disassembler, correct ".byte" output was limited to the first 64-bits
of an instruction. After that, zeroes are incorrectly printed.
Note that, it only happens on ".byte" output (instruction part) and not on
hexdump (data) part. For example, before this commit, hexdump and ".byte"
produces different values:
Assembly:
.insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f
objdump output example (before the fix):
10: 607f 33cc 55aa cdef .byte 0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
18: 89ab 4567 0123 3210
20: 7654 ba98 fedc
Note that, after 0xcd (after first 64-bits of the target instruction), all
".byte" values are incorrectly printed as zero while hexdump prints correct
instruction bits.
To resolve this, this commit adds "packet" argument to support dumping
instructions longer than 64-bits (to print correct instruction bits on
".byte"). This commit will be tested on the separate commit.
Assembly:
.insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f
objdump output example (after the fix):
10: 607f 33cc 55aa cdef .byte 0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe
18: 89ab 4567 0123 3210
20: 7654 ba98 fedc
opcodes/ChangeLog:
* riscv-dis.c (riscv_disassemble_insn): Print unknown instruction
using the new argument packet.
(riscv_disassemble_data): Add unused argument packet.
(print_insn_riscv): Pass packet to the disassemble function.
First of all make operand_type_register_match() apply to all sized
operands, i.e. in Intel Syntax also to respective memory ones. This
addresses gas wrongly accepting certain SIMD insns where register and
memory operand sizes should match but don't. This apparently has
affected all templates with one memory-only operand and one or more
register ones, both permitting at least two sizes, due to CheckRegSize
not taking effect.
Then also add CheckRegSize to a couple of non-SIMD templates matching
that same pattern of memory-only vs register operands. This replaces
bogus (for Intel Syntax) diagnostics referring to a wrong suffix (when
none was used at all) by "type mismatch" ones, just like already emitted
for insns where the template allows a register operand alongside a
memory one at any particular position.
This also is a prereq to limiting (ideally eliminating in the long run)
suffix "derivation" in Intel Syntax mode.
While making the code adjustment also flip order of checks to do the
cheaper one first in both cases.
To properly and predictably determine operand size encoding (operand
size or REX.W prefixes), consistent operand sizes need to be specified.
Add CheckRegSize where this was previously missing.
Both uniformly only ever take 16-bit memory operands while at the same
time requiring matching (in size) register operands, which then also
should disassemble that way. This in particular requires splitting each
of the templates for the assembler and separating decode of the
register and memory forms in the disassembler.
Mode/reg bits for these insns are 000 Dy, 001 Ay, and 111 100 for the
move immediate.
* m68k-opc.c (m68k_opcodes): Only accept 000 and 001 as mode
for move reg to macsr/mask insns.
This patch changes the address for "isa_config" auxiliary register
from 0xC2 to the correct value 0xC1. Moreover, it only exists in
arc700+ and not all ARCs.
opcodes/ChangeLog:
* arc-regs.h: Change isa_config address to 0xc1.
isa_config exists for ARC700 and ARCV2 and not ARCALL.
Use NoSuf to replace No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf
and add the explicit NoSuf to AddrPrefixOpReg in templates.
* i386-opc.tbl (NoSuf): New macro.
(AddrPrefixOpReg): Remove No_?Suf.
Replace No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf with
NoSuf in templates.
Add NoSuf to AddrPrefixOpReg in templates.
This patch adds the XTheadInt extension, which provides interrupt
stack management instructions.
The XTheadFmv extension is documented in the RISC-V toolchain
contentions:
https://github.com/riscv-non-isa/riscv-toolchain-conventions
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
This patch adds the XTheadFmv extension, which allows to access the
upper 32 bits of a double-precision floating-point register in RV32.
The XTheadFmv extension is documented in the RISC-V toolchain
contentions:
https://github.com/riscv-non-isa/riscv-toolchain-conventions
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Attributes which aren't used together in any single insn template can be
converted from individual booleans to a single enum, as was done for a few
other attributes before. This is more space efficient. Collect together
all attributes which express special operand constraints (and which fit
the criteria for folding).
On a testcase like
pla 8,foo@pcrel
disassembled with -Mpower10 results in
0: 00 00 10 06 pla r8,0 # 0
4: 00 00 00 39
0: R_PPC64_PCREL34 foo
but with -Mpower10 -Mraw
0: 00 00 10 06 .long 0x6100000
0: R_PPC64_PCREL34 foo
4: 00 00 00 39 addi r8,0,0
The instruction is unrecognised due to the hack we have in
extract_pcrel0 in order to disassemble paddi with RA0=0 and R=1 as
pla. I could have just added "&& !(dialect & PPC_OPCODE_RAW)" to the
condition in extract_pcrel0 under which *invalid is set, but went for
this larger patch that reorders the extended insn pla to the more
usual place before its underlying machine insn. (la is after addi
because we never disassemble to la.)
gas/
* testsuite/gas/ppc/raw.d,
* testsuite/gas/ppc/raw.s: Add pla.
opcodes/
* ppc-opc.c (extract_pcrel1): Rename from extract_pcrel0 and
invert *invalid logic.
(PCREL1): Rename from PCREL0.
(prefix_opcodes): Sort pla before paddi, adjusting R operand
for pla, paddi and psubi.
Although the encoding for scalar and fp registers is identical,
we should follow common pratice and use fp register names
when referencing fp registers.
The xtheadmemidx extension consists of indirect load/store instructions
which all load to or store from fp registers.
Let's use fp register names in this case and adjust the test cases
accordingly.
gas/
* testsuite/gas/riscv/x-thead-fmemidx-fail.l: Updated since rd need to
be float register.
* testsuite/gas/riscv/x-thead-fmemidx-fail.s: Likewise.
* testsuite/gas/riscv/x-thead-fmemidx.d: Likewise.
* testsuite/gas/riscv/x-thead-fmemidx.s: Likewise.
opcodes/
* riscv-opc.c (riscv_opcodes): Updated since rd need to be float register.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Hi all,
This wrong comment was introduced by previous AVX-VNNI-INT8 commit.
Committed as obvious fix.
BRs,
Haochen
opcodes/ChangeLog:
* i386-dis.c (VEX_W_0F3851): Corrected from
VEX_W_0F3851_P_0.
After this commit:
commit 6576bffe6c
Date: Thu Jul 7 13:43:45 2022 +0100
opcodes/arm: add disassembler styling for arm
Some people were seeing their builds failing with complaints about a
possible uninitialized variable usage. I previously fixed an instance
of this issue in this commit:
commit 2df82cd4b4
Date: Tue Nov 1 10:36:59 2022 +0000
opcodes/arm: silence compiler warning about uninitialized variable use
which did fix the build problems that the sourceware buildbot was
hitting, however, an additional instance of the same problem was
brought to my attention, and that is fixed in this commit.
Where commit 2df82cd4b4 fixed the uninitialized variable problem in
print_mve_unpredictable, this commit fixes the same problem in
print_mve_undefined.
As with the previous commit, I don't believe we could really ever get
an uninitialized variable usage, based on the current usage of the
function, so I have just initialized the reason variable to "??".
Prior to commit 1cb0ab18ad ("x86/Intel: restrict suffix derivation")
the Tbyte modifier on the FLDT and FSTPT templates was pointless, as
No_ldSuf would have prevented it being accepted. Due to the special
nature of LONG_DOUBLE_MNEM_SUFFIX said commit, however, has led to these
insns being accepted in Intel syntax mode even when "tbyte ptr" was
present. Restore original behavior by dropping Tbyte there. (Note that
these insns in principle should by marked AT&T syntax only, but since
they haven't been so far we probably shouldn't change that.)
The earlier commit:
commit 6576bffe6c
Date: Thu Jul 7 13:43:45 2022 +0100
opcodes/arm: add disassembler styling for arm
introduced two places where a register name was passed as the format
string to the disassembler's fprintf_styled_func callback. This will
cause a warning from some compilers, like this:
../../binutils-gdb/opcodes/arm-dis.c: In function ‘print_mve_vld_str_addr’:
../../binutils-gdb/opcodes/arm-dis.c:6005:3: error: format not a string literal and no format arguments [-Werror=format-security]
6005 | func (stream, dis_style_register, arm_regnames[gpr]);
| ^~~~
This commit fixes these by using "%s" as the format string.
