[PATCH 0/2] RISC-V: Make some instruction non-aliases to fix a disassembler issue
Tsukasa OI
research_trasio@irq.a4lg.com
Sat Jul 9 03:50:13 GMT 2022
Hello,
Certain instructions are defined as aliases (with INSN_ALIAS) but some
of them have no "parent" instructions (without INSN_ALIAS).
As a result, if the disassembler has given an option of `no-aliases',
they will be printed as `.4byte', unrecognized instructions.
This patchset fixes thie issue.
Note that zip/unzip fix is based on my previous patchset:
<https://sourceware.org/pipermail/binutils/2022-June/121159.html>
Changes since the patchset above are:
- Also fixed `fence.tso' instruction
- Added testcases (technically, added `-M no-aliases' to existing
tests to make sure that target instructions are not aliases)
Tracker on GitHub:
<https://github.com/a4lg/binutils-gdb/wiki/riscv_dis_nonalias>
Supersedes:
- <https://sourceware.org/pipermail/binutils/2022-June/121159.html>
(Tracker: <https://github.com/a4lg/binutils-gdb/wiki/riscv_dis_rv32_zip>)
Sidenote:
I started listing my Binutils submissions on my GitHub Wiki:
<https://github.com/a4lg/binutils-gdb/wiki/Patch-Queue>
hoping that current status and conflicting patches are clear.
1. zip/unzip (RV32_Zbkb) [PATCH 1]
`zip' and `unzip' are instructions from Zbkb extension (RV32 only).
They are, in fact, specialized forms of `shfli' and `unshfli'
instructions, respectively. The problem now is, since generalized
`shfli' and `unshfli' are not ratified AND `zip'/`unzip' are defined as
aliases (with INSN_ALIAS), it causes a problem on the diassembler.
With following assembler file with `-march=rv32i_zbkb',
_start:
zip a0, a1
unzip a2, a3
The output with `objdump -d' is like this:
80000028 <_start>:
80000028: 08f59513 zip a0,a1
8000002c: 08f6d613 unzip a2,a3
However, output with `objdump -d -M no-aliases' looks like this:
80000028 <_start>:
80000028: 08f59513 .4byte 0x8f59513
8000002c: 08f6d613 .4byte 0x8f6d613
You can see that `-M no-aliases' option causes disassembler to ignore
`zip'/`unzip' instructions but cannot find right non-alias instructions.
Until generalized `shfli' and `unshfli' instructions are ratified,
my simple patch (which makes `zip'/`unzip' non-aliases) does the trick.
Once generalized `shfli' and `unshfli' instructions are ratified, the
status will be a bit different. As the same issue is already present on
disassembling `zext.h' instruction on RV{32,64}_Zbb_Zbkb, this is to be
fixed with a different patchset:
<https://sourceware.org/pipermail/binutils/2022-June/121159.html>
2. fence.tso (RVI) [PATCH 2]
`fence.tso' is a subset of generalized `FENCE' instruction in the RISC-V
ISA. However, this is not the case on GNU Binutils.
Since we don't have proper way how to describe fm (fence mode) field in
an assembler mnemonic of the `FENCE' instruction, GNU Binutils' `fence'
instruction is defined as RISC-V `FENCE' instruction where fm=0b0000
(regular fence).
As a result, `fence.tso' (which has fm=0b1000) is not a subset of GNU
Binutils' `fence' (which has 0b0000). So, `fence.tso' must not be
defined as an alias (with INSN_ALIAS).
Tsukasa OI (2):
RISC-V: Make `zip'/`unzip' on Zbkb non-aliases
RISC-V: Make `fence.tso' a non-alias
gas/testsuite/gas/riscv/fence-tso.d | 2 +-
gas/testsuite/gas/riscv/zbkb-32.d | 2 +-
opcodes/riscv-opc.c | 6 +++---
3 files changed, 5 insertions(+), 5 deletions(-)
base-commit: d2acd4b0c5bab349aaa152d60268bc144634a844
--
2.34.1
More information about the Binutils
mailing list