aarch64 nop instruction

Eliot Miranda <[email protected]>
Newsgroups gmane.comp.gdb.devel,gmane.comp.gdb.bugs.general
Message-ID <CAC20JE2mFz5zVD9y9Gzcm6V_Kp3o4C-CMtmJCF2myryW50qf+Q@mail.gmail.com>
Hi All,

    I use gdb for processor simulation in a Smalltalk JIT.  I am using gdb
8.3.1 to derive an aarch64 (ARMV8) simulator.  I have noticed that 8.3.1
does not disassemble Arm's "approved" not instruction.

The approved nop is 2r1101010100000011001000000001111, 0x6a81900f, see
C6.2.202 on p 252 of
https://developer.arm.com/docs/ddi0487/ea/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile.
When I use the 8.3.1 derived system to disassemble that nop I get e.g.
00000000: .inst 0x6a81900f ; undefined


The entry in opcodes/aarch64-tbl.h for the nop that does disassemble is

CORE_INSN ("nop", 0xd503201f, 0xffffffff, ic_system, 0, OP0 (), {}, F_ALIAS)

I've tried adding
CORE_INSN ("nop", 0x6a81900f, 0xffffffff, ic_system, 0, OP0 (), {}, F_ALIAS)
which leaves 0xd503201f unaffected but still yields "undefined" for the
:"approved" nop.

I've tried adding
  CORE_INSN ("nop", 0x6a81900f, 0xffffffff, log_shift, 0, OP0 (), {},
F_HAS_ALIAS),
with the 0ther 0x6a opcodes, e.g.
  CORE_INSN ("bics", 0x6a200000, 0x7f200000, log_shift, 0, OP3 (Rd, Rn,
Rm_SFT), QL_I3SAMER, F_SF),
and this breaks the other nop, 0xd503201f, and both forms print as
undefined.

While I think that not disassembling the official nop is a bug I'm really
more interested in finding out what the minimal change to the table is to
get the "approved" nop to disassemble.  Can anyone help?
_,,,^..^,,,_
best, Eliot
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.