Re: aarch64 nop instruction
Andrew Pinski <[email protected]> Wed, 20 Nov 2019 14:09:15 -0800
| Newsgroups | gmane.comp.gdb.devel,gmane.comp.gdb.bugs.general |
|---|---|
| Message-ID | <CA+=Sn1=JwPgDajLpUiD2_RCmXx2k6Oc_o42w78v8RkgyCV2KYw@mail.gmail.com> |
On Wed, Nov 20, 2019 at 1:31 PM Eliot Miranda <[email protected]> wrote: > > 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 Resent out with the attached picture so it would goto the gdb list. Wait I think you are reading the number wrong and the ARM ARM incorrectly. I see (gdb) p/t 0xd503201f $2 = 11010101000000110010000000011111 This is exactly what is written in the ARM ARM as far as I can see. See attached picture. It ends in 5 1's which is 0x1f (you missed the one 1 too). starts with 1101 which is 0xd. I don't see where you get 6a from either. Are you thinking the value in memory; so you are reading it as a little-endian value or something different? Thanks, Andrew Pinski > 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