From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108638 invoked by alias); 2 Oct 2015 11:24:08 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 108618 invoked by uid 89); 2 Oct 2015 11:24:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-pa0-f50.google.com Received: from mail-pa0-f50.google.com (HELO mail-pa0-f50.google.com) (209.85.220.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 02 Oct 2015 11:24:06 +0000 Received: by pablk4 with SMTP id lk4so104089488pab.3; Fri, 02 Oct 2015 04:24:04 -0700 (PDT) X-Received: by 10.68.57.197 with SMTP id k5mr19370078pbq.142.1443785044416; Fri, 02 Oct 2015 04:24:04 -0700 (PDT) Received: from E107787-LIN.cambridge.arm.com (power-aix.osuosl.org. [140.211.15.154]) by smtp.gmail.com with ESMTPSA id yq2sm11561338pbb.39.2015.10.02.04.24.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 02 Oct 2015 04:24:03 -0700 (PDT) From: Yao Qi X-Google-Original-From: Yao Qi To: marcus.shawcroft@gmail.com Cc: gdb-patches@sourceware.org, binutils@sourceware.org Subject: [PATCH 0/3 V2] [aarch64] Use opcodes to decode instructions in GDB Date: Fri, 02 Oct 2015 11:24:00 -0000 Message-Id: <1443785039-24602-1-git-send-email-yao.qi@linaro.org> In-Reply-To: References: X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00015.txt.bz2 Hi Marcus, On 02/10/15 08:51, Marcus Shawcroft wrote: > I'll let others comment on the gdb aspect of this patch, w.r.t > opcodes, the aarch64-dis.h header is internal to opcodes. The public > interface to opcodes is exposed via include/opcode/aarch64.h or > include/dis-asm.h. The latter exposes just the cross architecture > disassembler interface so I think includes/opcode/aarch64.h is the > right choice in this case. OK, I move the declaration to includes/opcode/aarch64.h in V2. > > Before we expose this function, can we put in a patch to rename it to > following the name space convention used by the other exposed > functions, something like aarch64_disassemble_insn.? I think we should Patch #2 in V2 does this, but renames it to aarch64_decode_insn, because aarch64_decode_insn can be used in disassemble, but also in something else. > take the patch to drop the PC argument first, then rename and expose > the function, then the gdb patch to use the interface. OK, in V2, there are three patches. Patch #1 remove the PC argument, patch #2 exposes and renames disas_aarch64_insn, and patch #3 use it GDB. > >> >+/* Decode INSN and fill in *INST the instruction information. Return zero >> >+ on success. */ >> >+ >> >+int disas_aarch64_insn (uint32_t insn, aarch64_inst *inst); > The prototype should drop the formal argument names, irrespective of > which .h file it lands in. Fixed in V2. *** BLURB HERE *** Yao Qi (3): [aarch64] Remove argument pc from disas_aarch64_insn [aarch64] expose disas_aarch64_insn and rename it to aarch64_decode_insn [aarch64] use aarch64_decode_insn to decode instructions in GDB gdb/aarch64-tdep.c | 29 ++++++++++++++++++----------- include/opcode/aarch64.h | 3 +++ opcodes/aarch64-dis.c | 10 +++++----- 3 files changed, 26 insertions(+), 16 deletions(-) -- 1.9.1