* Extract all private_data initializations into riscv_init_disasm_info, which
called from print_insn_riscv rather than riscv_disassemble_insn.
* The disassemble_free_target seems like the right place to release all target
private_data, also including the internal data structures, like riscv_subsets.
Therefore, add a new function, disassemble_free_riscv, to release them for safe.
opcodes/
* disassemble.c (disassemble_free_target): Called disassemble_free_riscv
for riscv to release private_data and internal data structures.
* disassemble.h: Added extern disassemble_free_riscv.
* riscv-dis.c (riscv_init_disasm_info): New function, used to init
riscv_private_data.
(riscv_disassemble_insn): Moved riscv_private_data initializations
into riscv_init_disasm_info.
(print_insn_riscv): Called riscv_init_disasm_info to init
riscv_private_data once time.
(disassemble_free_riscv): New function, used to free the internal data
structures, like riscv_subsets.
Trying to build binutils with an older gcc currently fails. Working
around these gcc bugs is not onerous so let's fix them.
bfd/
* elf32-csky.c (csky_elf_size_dynamic_sections): Don't type-pun
pointer.
* elf32-rl78.c (rl78_compute_complex_reloc): Rename "stat"
variable to "status".
gas/
* compress-debug.c (compress_finish): Supply all fields in
ZSTD_inBuffer initialisation.
include/
* xtensa-dynconfig.h (xtensa_isa_internal): Delete unnecessary
forward declaration.
opcodes/
* loongarch-opc.c: Supply all fields of zero struct initialisation
in various opcode tables.
Consistently do 64-bit first, VEX.L second, VEX.W third, ModR/M fourth,
and only then prefix, resulting in fewer table entries. Note that in the
course of the re-work
- TILEZERO has a previously missing decode step through rm_table[]
added,
- a wrong M_0 suffix for TILEZERO is also corrected to be M_1 (now an
infix).
Consistently do 64-bit first, ModR/M second, VEX.L third, VEX.W fourth,
and prefix last, resulting in fewer table entries. Note that in the
course of the re-work wrong M_0 suffixes are also corrected to be M_1
(partly infixes now).
Since it ended up confusing while testing the change, also adjust the
test name in x86-64-amx-bad.d (to be distinct from x86-64-amx.d's).
Ventana Micro has published the specification for their
XVentanaCondOps ("conditional ops") extension at
https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf
which contains two new instructions
- vt.maskc
- vt.maskcn
that can be used in constructing branchless sequences for
various conditional-arithmetic, conditional-logical, and
conditional-select operations.
To support such vendor-defined instructions in the mainline binutils,
this change also adds a riscv_supported_vendor_x_ext secondary
dispatch table (but also keeps the behaviour of allowing any unknow
X-extension to be specified in addition to the known ones from this
table).
As discussed, this change already includes the planned/agreed future
requirements for X-extensions (which are likely to be captured in the
riscv-toolchain-conventions repository):
- a public specification document is available (see above) and is
referenced from the gas-documentation
- the naming follows chapter 27 of the RISC-V ISA specification
- instructions are prefixed by a vendor-prefix (vt for Ventana)
to ensure that they neither conflict with future standard
extensions nor clash with other vendors
bfd/ChangeLog:
* elfxx-riscv.c (riscv_get_default_ext_version): Add riscv_supported_vendor_x_ext.
(riscv_multi_subset_supports): Recognize INSN_CLASS_XVENTANACONDOPS.
gas/ChangeLog:
* doc/c-riscv.texi: Add section to list custom extensions and
their documentation URLs.
* testsuite/gas/riscv/x-ventana-condops.d: New test.
* testsuite/gas/riscv/x-ventana-condops.s: New test.
include/ChangeLog:
* opcode/riscv-opc.h Add vt.maskc and vt.maskcn.
* opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_XVENTANACONDOPS.
opcodes/ChangeLog:
* riscv-opc.c: Add vt.maskc and vt.maskcn.
Series-version: 1
Series-to: binutils@sourceware.org
Series-cc: Kito Cheng <kito.cheng@sifive.com>
Series-cc: Nelson Chu <nelson.chu@sifive.com>
Series-cc: Greg Favor <gfavor@ventanamicro.com>
Series-cc: Christoph Muellner <cmuellner@gcc.gnu.org>
1) i386-dis.c:12055:11: runtime error: left shift of negative value -1
Bit twiddling is best done unsigned, due to UB on overflow of signed
expressions. Fix this by using bfd_vma rather than bfd_signed_vma
everywhere in i386-dis.c except print_displacement.
2) Return get32s and get16 value in a bfd_vma, reducing the need for
temp variables.
3) Introduce get16s and get8s functions to simplify the code.
4) With some optimisation options gcc-13 legitimately complains about
a fall-through in OP_I. Fix that. OP_I also doesn't need to use
"mask" which was wrong for w_mode anyway.
5) Masking with & 0xffffffff is better than casting to unsigned. We
don't know for sure that unsigned int is 32-bit.
6) We also don't know that unsigned char is 8 bits. Mask codep
accesses everywhere. I don't expect binutils will work on anything
other than an 8-bit char host, but if we are masking codep accesses in
some places we might as well be consistent. (Better would be to use
stdint.h types more in binutils.)
opcodes/i386-dis.c: In function ‘print_insn’:
opcodes/i386-dis.c:9865:22: error: storing the address of local
variable ‘priv’ in ‘*info.private_data’ [-Werror=dangling-pointer=]
* i386-dis.c (print_insn): Clear info->private_data before
returning.
For quite come time print_insn() has been storing the address of a local
variable into info->private_data. Since the compiler can't know that the
field won't be accessed again after print_insn() returns, it may kind of
legitimately diagnose this. And recent enough gcc does as of the
introduction of the fetch_error() return paths (replacing setjmp()-based
error handling).
Utilizing that neither prefix_name() nor i386_dis_printf() actually use
info->private_data, zap the pointer in fetch_error(), after having
retrieved it for local use.
A recent change in opcodes/i386-dis.c caused a build failure on my
x86-64 Fedora 36 system, which uses:
$ gcc --version
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
[...]
The error is:
../../binutils-gdb/opcodes/i386-dis.c: In function ‘OP_J’:
../../binutils-gdb/opcodes/i386-dis.c:12705:22: error: ‘val’ may be used uninitialized [-Werror=maybe-uninitialized]
12705 | disp = val & 0x8000 ? val - 0x10000 : val;
| ~~~~^~~~~~~~
This patch fixes the warning.
opcodes/ChangeLog
2023-04-21 Tom Tromey <tromey@adacore.com>
* i386-dis.c (OP_J): Check result of get16.
get64() is unreachable when !BFD64 (due to a check relatively early in
print_insn()). Let's avoid the associated #ifdef-ary (or else we should
extend it to remove more dead code).
Make them return boolean and convert FETCH_DATA() uses to fetch_code().
With this no further users of FETCH_DATA() remain, so the macro and its
backing function are dropped as well.
Leave value types as they were for the helper functions, even if I don't
think that beyond get64() use of bfd_{,signed_}vma is really necessary.
With type change of "disp" in OP_E_memory(), change the 2nd parameter of
print_displacement() to a signed type as well, though (eliminating the
need for a local variable of signed type). This also eliminates the need
for custom printing of '-' in Intel syntax displacement expressions.
While there drop forward declarations which aren't really needed.
Use a tristate (enum) return value type to be able to express all three
cases which are of interest to the (sole) caller. This also allows doing
away with the abuse of "rex_used".
... and its direct helper get_sib(). Using setjmp()/longjmp() for fetch
error handling is problematic, as per
https://sourceware.org/pipermail/binutils/2023-March/126687.html. Start
using more conventional error handling instead.
Also introduce a fetch_modrm() helper, for subsequent re-use.
... such that it can be used from other than the setjmp() error handling
path.
Since I'd like the function's parameter to be pointer-to-const, two
other functions need respective constification then, too (along with
needing to be forward-declared).
This issue was reported from https://github.com/riscv-collab/riscv-gnu-toolchain/issues/1188
Current flow:
1) Scan any mapping symbol less than this instruciton.
2) If not found, did a backward search.
The flow seems not big issue, let run an example here:
$x:
0x0 a <--- Found at step 1
0x4 b <--- Not found in step 1, but found at step 2
0x8 c <--- Not found in step 1, but found at step 2
$d
0x12 .word 1234 <-- Found at step 1
The instruciton didn't have the same address with mapping symbol will
still did backward search again and again.
So the new flow is:
1) Use the last mapping symbol status if the address is still within the range
of the current mapping symbol.
2) Scan any mapping symbol less than this instruciton.
3) If not found, did a backward search.
4) If a proper mapping symbol is found in either step 2 or 3, find its boundary,
and cache that.
Use the same example to run the new flow again:
$x:
0x0 a <--- Found at step 2, the boundary is 0x12
0x4 b <--- Cache hit at step 1, within the boundary.
0x8 c <--- Cache hit at step 1, within the boundary.
$d
0x12 .word 1234 <-- Found at step 2, the boundary is the end of section.
The disassemble time of the test cases has been reduced from ~20 minutes to ~4
seconds.
opcode/ChangeLog
PR 30282
* riscv-dis.c (last_map_symbol_boundary): New.
(last_map_state): New.
(last_map_section): New.
(riscv_search_mapping_symbol): Cache the result of latest
mapping symbol.
While I was working on the disassembler styling for ARM I noticed that
the whitespace in the cpsie instruction was inconsistent with most of
the other ARM disassembly output, the disassembly for cpsie looks like
this:
cpsie if,#10
notice there's no space before the '#10' immediate, most other ARM
instructions have a space before each operand.
This commit updates the disassembler to add the missing space, and
updates the tests I found that tested this instruction.
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.
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.
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.
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.
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.
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.
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.
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.
