From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46001 invoked by alias); 20 Nov 2019 22:17:49 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 45988 invoked by uid 89); 20 Nov 2019 22:17:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM,SPF_SOFTFAIL autolearn=no version=3.3.1 spammy=H*r:bug-gdb@gnu.org, H*f:sk:CAC20JE, 0xd, sk:eliotm X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Nov 2019 22:17:46 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49317) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iXYIC-0004z1-FU for gdb@sourceware.org; Wed, 20 Nov 2019 17:17:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42787) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iXYIC-00015p-55 for bug-gdb@gnu.org; Wed, 20 Nov 2019 17:17:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iXYIA-0004xB-Vq for bug-gdb@gnu.org; Wed, 20 Nov 2019 17:17:44 -0500 Received: from mail-vs1-xe2f.google.com ([2607:f8b0:4864:20::e2f]:46036) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iXYIA-0004vp-OC for bug-gdb@gnu.org; Wed, 20 Nov 2019 17:17:42 -0500 Received: by mail-vs1-xe2f.google.com with SMTP id n9so800967vsa.12 for ; Wed, 20 Nov 2019 14:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RCwdxeV7GOYWNDTurlNU9+ja2r1mndiHja9LabdXhH8=; b=LkrbX3VrmS1LPa221/EqDBR5taEZ6qSCJTmdqOq+PRhH0Hjp3F3g6as+wdBquzGZ8f RXsrA76E+p5xwUF4RAfgv2NgHGVfY3cbK2UT+mbqKv0gpZRjJTgxohefXJnGQUMc+A7p FpQEGjAchVh7oroqTQ7uHtpCuaYwX8Yx2i9see3/u9BWk+HU2CfyIJvYY4k0d3ySUzW5 njetfJGLMD1B5VGATKsynQHaM55ZJXsZPyKRCKMkRcR9hsNXWraPnBwrhDzoHHWDRvwU fJaU8PEroMOeYgDNj8QIKQW1k1IcVDR4YZSH40M+rOxfEPBHRJGsluu7j9lEdlPPPMhW J3cg== MIME-Version: 1.0 References: In-Reply-To: From: Andrew Pinski Date: Wed, 20 Nov 2019 22:17:00 -0000 Message-ID: Subject: Re: aarch64 nop instruction To: Eliot Miranda Cc: bug-gdb@gnu.org Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::e2f X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg00036.txt.bz2 On Wed, Nov 20, 2019 at 2:09 PM Andrew Pinski wrote: > > On Wed, Nov 20, 2019 at 1:31 PM Eliot Miranda 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? Just FYI: (gdb) p/x 0x6a81900f<<1|1 $6 = 0xd503201f It does look like you are missing the last 1 when you were reading the ARM ARM :). Thanks, Andrew Pinski > > > 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