From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125128 invoked by alias); 20 Nov 2019 21:31:34 -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 125120 invoked by uid 89); 20 Nov 2019 21:31:34 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,SPF_SOFTFAIL autolearn=no version=3.3.1 spammy=H*r:bug-gdb@gnu.org, simulator, H*c:alternative, HTo:U*bug-gdb 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 21:31:32 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48598) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iXXZS-0005kz-FZ for gdb@sourceware.org; Wed, 20 Nov 2019 16:31:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37205) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iXXZS-0004HW-1G for bug-gdb@gnu.org; Wed, 20 Nov 2019 16:31:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iXXZQ-0005kc-P1 for bug-gdb@gnu.org; Wed, 20 Nov 2019 16:31:29 -0500 Received: from mail-qt1-x830.google.com ([2607:f8b0:4864:20::830]:37425) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iXXZQ-0005kC-Bh for bug-gdb@gnu.org; Wed, 20 Nov 2019 16:31:28 -0500 Received: by mail-qt1-x830.google.com with SMTP id g50so1214633qtb.4 for ; Wed, 20 Nov 2019 13:31:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=BtHYAxhXxQ4G7O8X96kXCFN6J46zdBEAQwyJgF8kPSc=; b=a4nKP0eGxTubtCFpPu0S2USekF3jzOeKpF/q6gFL8p5P6KOBIRZZzLihBpXtZXcU1I Nd2r2l0OXppK8RwDxI+nxRu5Tie5cS6FX7RBcFviYy5w7wwgM0ppvSWPykNglQajt5zt LJp0mYZ24Wnpu2tO6FQ6Ichi1bqI1mriJuwq2Q/97M8FqLKilaAV8ZQUsVqPcR0vGo+R owcA6xiDTPRh7Nz3onSRa5qM9l2p7AZHoXUn1hrDip4G+ZHgWiBq+GMl4wjzylrTXBDa fndXAeBxhR+NhZxVcyQ0S4kZ7+UFaFTS//XmNx7xFZK03SscYqPnl7NgfPutNWSSP6cF +osQ== MIME-Version: 1.0 From: Eliot Miranda Date: Wed, 20 Nov 2019 21:31:00 -0000 Message-ID: Subject: aarch64 nop instruction To: bug-gdb@gnu.org X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::830 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2019-11/txt/msg00034.txt.bz2 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