From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113740 invoked by alias); 24 Jan 2017 13:41:09 -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 113724 invoked by uid 89); 24 Jan 2017 13:41:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=17-01-17, print_insn_mep, mep, sk:mep_gdb 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, 24 Jan 2017 13:41:06 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtp id 1cW1LM-0005aM-T2 from Luis_Gustavo@mentor.com ; Tue, 24 Jan 2017 05:41:04 -0800 Received: from [172.30.8.148] (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, 24 Jan 2017 05:41:01 -0800 Reply-To: Luis Machado 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> <20170124100805.GQ28060@E107787-LIN> To: Yao Qi CC: From: Luis Machado Message-ID: Date: Tue, 24 Jan 2017 13:41: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: <20170124100805.GQ28060@E107787-LIN> Content-Type: text/plain; charset="utf-8"; 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/msg00493.txt.bz2 On 01/24/2017 04:08 AM, Yao Qi wrote: > On 17-01-17 08:19:18, Luis Machado wrote: >> On 01/16/2017 04:02 AM, Yao Qi wrote: >>> >>> -/* 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? >> > > That is the implementation detail of print_insn_mep (provided by opcodes), > and gdb should not know about. Both gdb and objdump are the clients of > opcodes, and they need to provide precise information as much as it can. > However, they shouldn't know that what should print_insn_mep do. > Fair enough. But in that case we still have a chunk of code in that function explaining why the section is being used. Should that go away too? /* The libopcodes disassembly code uses the section to find the BFD, the BFD to find the ELF header, the ELF header to find the me_module index, and the me_module index to select the right instructions to print. */