From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 1DF013857828 for ; Mon, 22 Mar 2021 15:06:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1DF013857828 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 12MF6OGs030425 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Mar 2021 11:06:29 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 12MF6OGs030425 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 5A1421E789; Mon, 22 Mar 2021 11:06:24 -0400 (EDT) Subject: Re: flag to know that we are compiling GDB for an arm target To: Zied Guermazi , "Metzger, Markus T" , "gdb@sourceware.org" References: <2a6681a1-f672-0ae9-3aa7-8001330a8661@trande.de> <73d48246-983d-5b0b-be40-dee0423daf43@polymtl.ca> <4d77ba55-5ca6-4b44-2cc7-ecbb37ff26b6@trande.de> <0f6dc0a0-ad67-5247-34a1-8b22f41087ca@polymtl.ca> <57c29c80-57e1-8c93-592e-f2cb11ff4ae1@trande.de> <2ab101e8-5e75-717e-9d87-11d1c4aa0f91@trande.de> From: Simon Marchi Message-ID: <8c00ecf0-ca44-0729-b576-8347078dc324@polymtl.ca> Date: Mon, 22 Mar 2021 11:06:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <2ab101e8-5e75-717e-9d87-11d1c4aa0f91@trande.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 22 Mar 2021 15:06:24 +0000 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 15:06:34 -0000 On 2021-03-22 10:53 a.m., Zied Guermazi wrote: > hi > > I will put different solutions together with advantages disadvantages > > - add a vector of registers to each instruction > > advantage: close to the logical model: a function is a set of instructions, an instruction changes a set of registers. > > disadvantage: consumes much memory (3 additional pointers, for an empty vector) > > - extend the instruction class > > advantage: targets not needing the registers are not heavily impacted > > disadvantages: still an additional pointer is added > > - Infer the ISA mode from mapping symbols > > advantages: no overhead in the data structure > > disadvantages: dwarf info are not always available. The mapping symbols (if I understand correctly, $a and $t) are not in the DWARF, they are ELF symbols. However, is it possible to record execution when you don't event have and ELF file, just connect to a target and record it? In that case, you might not even have ELF symbols, so that's perhaps not sufficient. There's also the case of self-modifying or JIT-ed code, where mapping symbols from the ELF file are of no use. So I think it's better to just always rely on CPSR. > - use additional bits in btrace_insn_flag > > advantages: no memory overhead > > disadvantages: encode architecture specific info. Since we already pay the cost of having space for flags, we might as well use it. It sounds like a good solution for your current problem, since there is very little info you need to keep (the execution mode). That doesn't solve the problem for when you'll want to record data though, a more flexible solution will be needed. > I will go for using additional bits (bit 1, bit 2 and bit 3) in btrace_insn_flag to encode the isa for armv7 as folowing > > ocsd_isa_arm as 0x02 > > ocsd_isa_thumb2 as 0x04 > > ocsd_isa_tee as 0x06 > > ocsd_isa_jazelle as 0x08 Is that 0x06 really what you want, it's a OR of arm and thumb2? Simon