From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nx231.node02.secure-mailgate.com (nx231.node02.secure-mailgate.com [192.162.87.231]) by sourceware.org (Postfix) with ESMTPS id 05E253858D29 for ; Mon, 22 Mar 2021 03:59:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 05E253858D29 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 1lOBjF-007Yse-Ox; Mon, 22 Mar 2021 04:59:46 +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 1B8BF34020F; Mon, 22 Mar 2021 04:59:45 +0100 (CET) X-SecureMailgate-Identity: host202.checkdomain.de Subject: Re: flag to know that we are compiling GDB for an arm target To: 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> From: Zied Guermazi Message-ID: <57c29c80-57e1-8c93-592e-f2cb11ff4ae1@trande.de> Date: Mon, 22 Mar 2021 04:59:44 +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: <0f6dc0a0-ad67-5247-34a1-8b22f41087ca@polymtl.ca> Content-Language: en-US X-PPP-Message-ID: <20210322035945.2709760.29793@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.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5xyqEdt6CnQhppeSX/xINWPhI8gjzT9yHEM1fHPv+pm9tzr cyixydPSsneZ1BAaVhAgiifvPJN7o5v5p11VZDvDWzSa/Xc66CKHObdl7quvBHiaS8Y2jxxNQPzs mflfncQrJi6CkYFzkjaHBJraKGbDUoTh9tkkYGx1qtbnIjA6A6BwWa8cajBO5gqeN2AIQ16CGBTJ idGkO5Wg/gxk2VGo/f9yFbPaRdV9pEVZXxSfijJy4s/VIlxaxVsRyE3LY4I6BdXMG2RHCbYXm0yX oT6953RC/CG1waUYjHz+OVs+/MJZNyIpGgGGGsus8M2p/IxNUUJZ/IufLAu0aou2zESnOyjxhhMr RWTIXc5j7r1BCeLwejJoep85cxiiuAjU3RbjzYhtI7KWl4upu2taQUcpU1v6P8H8HmLEncfJZqRO AyL7Drw3sIKaPf9gZxYkzOWzIh1wkn5B+muMTuS2LDwzt8Ds8HhMu8AsuC+XP0IWdUNAcfNPeAaq NHi4kbeS2lR+mBa4cVcOYt9AmTHtPiSqh0AHFmknmFY8AF9C3TOjZ64Dt0gTEK9vOlOvpFXXjOyu cj735mFcFqoc4yysvQM8ASJFC/49WOPBr5nlEUI4xHgy/s8+V7u/kltJ7ufnc1JhspljkOhpjzwd mRUuxUAk5aCBuR9hcz/feI6iGbWovIf8qU00v5FHzOwCBepHTTtczFDpKPmpCfZ05DAFWFwk/xMl GH0grBJyegCMlHzlnVvxDejqc1gSvA2YxCROcMITrk9wwq6nH7z/b3gCyLA3PYdd1oCahOM16hr6 AO8eXYhJROLx8jGN5zNmfPXo/ahKA3NaRiz5Dg+hVS6pgXVpHro5DQ2iNQWS+MZYXqhS1hBk5esg nrjfJcDjFNArNy16jvJsmaZpbKRZNsABnVcYKikgpr5a1aTmhXuiI3CY91H/RFhoL/xK5aoGOYne c8/eNHk15VolAGHS5rCXQKDyobCt/wGAR9cc6eDFZM4JJoFMAHPtwOQB8Z6hXNeHA1Q5V2emJ7Kj NAkyx+8lFLm6K0qQ84xLY31/Pjh5eHMlOjpBMzSqSrksJTjFvJG4Pe4= X-Report-Abuse-To: spam@node04.secure-mailgate.com X-Spam-Status: No, score=2.3 required=5.0 tests=BAYES_00, FOREIGN_BODY1, HTML_MESSAGE, 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 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 03:59:49 -0000 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.