From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60374 invoked by alias); 17 Jan 2017 14:19:35 -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 59309 invoked by uid 89); 17 Jan 2017 14:19:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_40,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=UD:68b0c4b..b1dcc86, UD:.b1dcc86, obj_section, mep_print_insn X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Jan 2017 14:19:24 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1cTUbb-00020u-3p from Luis_Gustavo@mentor.com ; Tue, 17 Jan 2017 06:19:23 -0800 Received: from [172.30.8.199] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 17 Jan 2017 06:19:19 -0800 Subject: Re: [PATCH 3/6] Call print_insn_mep in mep_gdb_print_insn References: <1484051178-16013-1-git-send-email-yao.qi@linaro.org> <1484560977-8693-1-git-send-email-yao.qi@linaro.org> <1484560977-8693-4-git-send-email-yao.qi@linaro.org> To: Yao Qi , Reply-To: Luis Machado From: Luis Machado Message-ID: Date: Tue, 17 Jan 2017 14:19:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1484560977-8693-4-git-send-email-yao.qi@linaro.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00322.txt.bz2 On 01/16/2017 04:02 AM, Yao Qi wrote: > opcodes/mep-dis.c:mep_print_insn has already had the code to > handle the case when info->section is NULL, > > /* Picking the right ISA bitmask for the current context is tricky. */ > if (info->section) > { > } > else /* sid or gdb */ > { > } > > so that we can still cal print_insn_mep even section can't be found. > On the other hand, user can disassemble an arbitrary address which > doesn't map to any section at all. > > gdb: > > 2017-01-10 Yao Qi > > * mep-tdep.c (mep_gdb_print_insn): Set info->arch > to bfd_arch_mep. Don't return 0 if section is not > found. Call print_insn_mep. > --- > gdb/mep-tdep.c | 10 +++------- > 1 file changed, 3 insertions(+), 7 deletions(-) > > diff --git a/gdb/mep-tdep.c b/gdb/mep-tdep.c > index 68b0c4b..b1dcc86 100644 > --- a/gdb/mep-tdep.c > +++ b/gdb/mep-tdep.c > @@ -1266,13 +1266,12 @@ mep_pseudo_register_write (struct gdbarch *gdbarch, > > /* Disassembly. */ > > -/* The mep disassembler needs to know about the section in order to > - work correctly. */ Instead of removing the comment, should we point out what the effects of having/not having section info will be? > static int > mep_gdb_print_insn (bfd_vma pc, disassemble_info * info) > { > struct obj_section * s = find_pc_section (pc); > > + info->arch = bfd_arch_mep; > if (s) > { > /* The libopcodes disassembly code uses the section to find the > @@ -1280,12 +1279,9 @@ mep_gdb_print_insn (bfd_vma pc, disassemble_info * info) > the me_module index, and the me_module index to select the > right instructions to print. */ > info->section = s->the_bfd_section; > - info->arch = bfd_arch_mep; > - > - return print_insn_mep (pc, info); > } > - > - return 0; > + > + return print_insn_mep (pc, info); > } > > > Otherwise looks OK.