From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nx213.node02.secure-mailgate.com (nx213.node02.secure-mailgate.com [192.162.87.213]) by sourceware.org (Postfix) with ESMTPS id 214823858004 for ; Mon, 22 Mar 2021 14:54:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 214823858004 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=trande.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=zied.guermazi@trande.de Received: from host202.checkdomain.de ([185.137.168.148]) by node02.secure-mailgate.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1lOLwO-0096r3-6c; Mon, 22 Mar 2021 15:54:01 +0100 X-SecureMailgate-Identity: host202.checkdomain.de Received: from [192.168.178.48] (x4dbd4c14.dyn.telefonica.de [77.189.76.20]) (Authenticated sender: zied.guermazi@trande.de) by host202.checkdomain.de (Postfix) with ESMTPSA id 8D74334021A; Mon, 22 Mar 2021 15:53:57 +0100 (CET) X-SecureMailgate-Identity: host202.checkdomain.de Subject: Re: flag to know that we are compiling GDB for an arm target To: "Metzger, Markus T" , Simon Marchi , "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> From: Zied Guermazi Message-ID: <2ab101e8-5e75-717e-9d87-11d1c4aa0f91@trande.de> Date: Mon, 22 Mar 2021 15:53:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-PPP-Message-ID: <20210322145358.1264671.49330@host202.checkdomain.de> X-PPP-Vhost: trande.de X-Originating-IP: 185.137.168.148 X-SecureMailgate-Domain: host202.checkdomain.de X-SecureMailgate-Username: 185.137.168.148 Authentication-Results: secure-mailgate.com; auth=pass smtp.auth=185.137.168.148@host202.checkdomain.de X-SecureMailgate-Outgoing-Class: ham X-SecureMailgate-Outgoing-Evidence: Combined (0.10) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT99zFCdxeSboWNKoZkeOgFGPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5xepKJyYLZISh0ScmnJxtOQL++T0fzDkcbraJCnPSgcQp91 ADy6bERTai4lQUfi0ov8b0HBt1XxwT2dNX3uS9wPcZmGlrSbXcSPbv3Gvk7oTkyC4eJXgSa0625S 60JUzdRtlSy40scZlFgLPtCr9SjEQp18NgnGCsx1bmdbb4szydP1+0zGDBEL130M02qMC0xQQhQ3 cXtTqZg6zYv+9efs/3vpuC4FAH4JcvbUWkbVjlvDRwp5U4jfYMAI/BBCrWaDwIE7VKe+bqpcdCns 72R1mlXslD7dplOOl8u9l7Br8NgwkGMnnSmiQIWE0h92BVmAd9sXdiOHyQc5jb5UsXBPtIMjc0Hv rCoIShx9Egj+5Y+JGC12hEo3bceCxZ00pJHUeeKYPM7sNcCy02izXOJhm4aVlBObnVhI6K7gAuPO 44MKM78T+LcmbVApU1OtExg2rRldRnnnohbUS3YD3Jmemtj2kTuR+vfsAwCLZsSPL9ckMeF4hOay CbDJxxTX92I93SsS4aMXJmiJ2G0eb5ah5Q4VQAf9BGA/4589jmSb+rM5VcI9Z9iQLx1EhkIGnvdO B2XvjaW5uTwPc8WgwrrudZBcpDAIWdCADSwEOtnmZWoMdUyXUOAkAA03/kA2wnXIHYi/jghIJpVk vIZQze0BrE7uWy+cBHv3/b8naGjYIYu2YiRYSRoqs6XmmhhLlvhFJHzS3oSyV+evCJACDe96N1vl 9cBTxWFG2vZmPXbe8xu1F07ZTzG5p6pYQpZ8qnXD/V3AlLsOWpVGhJKQeyhTzO+LPg7xISr2Y+Dy 8YCrK7734QDJ3HhluVo9DS81JHGO0ZkW2vkOTJT9oRh6vnQYYIwr1LRqMP9BI0FRUBYt7kDCoutW OwUwcUtXuUhAZLY7gqll0qssN4lx/Dun58B7nDqBzt/h+lyjaFmwbbCd48OpyKA69LF1Ge2GaGfx mfqx6SI8+0/Lb/TTMB8FF2VYA1/xx+UuuEf3h3NtOf+zHWCI6y95aUyb0ByL/85xvAwowAOZKBM6 e/bYB566DxuD5CO0yszN6JvP5bqvQPT9H/5uM2OaT1C8sNNRiDFO0DtShOH22SRgbHWq1uciMDoD 4FQ8ADxJsoknBaXqeoa4KA== X-Report-Abuse-To: spam@node04.secure-mailgate.com X-Spam-Status: No, score=2.5 required=5.0 tests=BAYES_00, FOREIGN_BODY1, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: ** 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 14:54:13 -0000 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. - Compression methods (BTRACE_INSN_AUX, BTRACE_INSN_ISA)     advantage: less memory overhead     disadvantages: requires traveling the vector to find the register value and match it with the instruction - use additional bits in btrace_insn_flag     advantages: no memory overhead     disadvantages: encode architecture specific info. 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 Kind Regards Zied Guermazi On 22.03.21 09:29, Metzger, Markus T wrote: > With class hierarchies, you'd end up allocating each object independently > and adding a pointer to the overall cost. > > For calculating the target IP of any given recorded instruction, we'd just > look at the next instruction in the trace, wouldn't we? > > Can we infer the ISA mode from mapping symbols? Or we could annotate > changes to the ISA mode in the trace. Some time ago, Felix had proposed > a new insn class BTRACE_INSN_AUX; instead of storing the PC, it would store > an index into a string vector. This could be generalized to store an index > into some tagged auxiliary object vector. > > Or, more simply, add a new insn class BTRACE_INSN_ISA that stores an > arch-specific ISA enum instead of the PC. > > We could further compress struct btrace_insn to store the iclass in 8b > to make room for another 16b field. > > Or reserve some flags encoding space for arch-specific information > like the ISA mode. > > Regards, > Markus. > >> -----Original Message----- >> From: Gdb On Behalf Of Zied Guermazi >> Sent: Montag, 22. März 2021 05:00 >> To: Simon Marchi ; gdb@sourceware.org >> Subject: Re: flag to know that we are compiling GDB for an arm target >> >> Thanks simon, >> >> it is elegant to solve it during instantiation. >> >> /Zied >> >> On 22.03.21 04:40, Simon Marchi wrote: >>> On 2021-03-21 10:46 p.m., Zied Guermazi wrote: >>>> hi Simon, >>>> >>>> I am extending btrace for armv7 and armv8. In armv7, due to some limitations >> in the debug HW, GDB requires the current program status register CPSR to know >> in which ISA mode it is, so that it can set breakpoints properly and calculate the >> "landing" address for next, nexti, step commands >>>> When we use the traces in replay mode we need to know and provide the cpsr >> at any instruction. >>>> there is a data structure (btrace_insn in btrace.h) that was extended to holds >> cpsr register and possibly other registers (paving the way for data tracing). >> currently it is a vector of registers, that will be (currently) empty of all >> architectures except ARMv7 (see the struct below). We have typically thousands >> to millions instances of this structure. >>>> >>>> struct btrace_insn >>>> { >>>> /* The address of this instruction. */ >>>> CORE_ADDR pc; >>>> >>>> /* The size of this instruction in bytes. */ >>>> gdb_byte size; >>>> >>>> /* A vector of registers. */ >>>> std::vector registers; >>>> >>>> /* The instruction class of this instruction. */ >>>> enum btrace_insn_class iclass; >>>> >>>> /* A bit vector of BTRACE_INSN_FLAGS. */ >>>> btrace_insn_flags flags; >>>> }; >>>> >>>> >>>> the empty vector was judged to be a big overhead for Intel PT for example. I >> am looking for a way to inhibit it, when we are not building GDB for armv7. >>>> do you have any proposal for solving such a situation? >>> Bearing in mind that I don't know this problem in detail, it sounds like >>> if making btrace_insn bigger isn't an option, then you'll want to have a >>> specific subclass for ARM (btrace_insn_arm), that adds the extra data. >>> However, since btrace_insn is used in a vector of objects in >>> btrace_function, then maybe you'll also need a specific >>> btrace_function_arm (btrace_function would keep using a vector of >>> btrace_insn, btrace_function_arm would use a vector of btrace_insn_arm. >>> Similarly, you might need a btrace_thread_info_arm, because >>> btrace_thread_info contains a vector of btrace_function. But then it's >>> not clear how that would interface with struct thread_info, to be able >>> to choose the right kind at runtime. I suppose that would involve a >>> class hierarchy with some virtual functions, where on Intel >>> btrace_thread_info is instantiated, and on ARM btrace_thread_info_arm is >>> instantiated. Ideally, all without introducing too much virtual >>> function calls on the fast path. >>> >>> Simon >> -- >> >> *Zied Guermazi* >> founder >> >> Trande UG >> Leuschnerstraße 2 >> 69469 Weinheim/Germany >> >> Mobile: +491722645127 >> mailto:zied.guermazi@trande.de >> >> *Trande UG* >> Leuschnerstraße 2, D-69469 Weinheim; Telefon: +491722645127 >> Sitz der Gesellschaft: Weinheim- Registergericht: AG Mannheim HRB 736209 >> - Geschäftsführung: Zied Guermazi >> >> *Confidentiality Note* >> This message is intended only for the use of the named recipient(s) and >> may contain confidential and/or privileged information. If you are not >> the intended recipient, please contact the sender and delete the >> message. Any unauthorized use of the information contained in this >> message is prohibited. >> > Intel Deutschland GmbH > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928