From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id LmeUBKYRWGAeDgAAWB0awg (envelope-from ) for ; Sun, 21 Mar 2021 23:40:22 -0400 Received: by simark.ca (Postfix, from userid 112) id 0B4DB1EF78; Sun, 21 Mar 2021 23:40:22 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 51CB31E590 for ; Sun, 21 Mar 2021 23:40:21 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BB08F3858D29; Mon, 22 Mar 2021 03:40:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BB08F3858D29 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1616384420; bh=4YGJEJDyQUupeddDHbAqfzb/EJqdRqVsUGyoz8PdAPM=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=eX4wS5vkmOhwGJ2b+37NoNRIcAVTs9pk5Uek90kKiEH6aM6y+3XxKyNC0ZtZWYWyA d4UtkE2QXmS1xJAR0HoRjAuPAcavohcpdWXeUr0RAdBRk57LGsX990V6KtsviF2QYr yJccijC2XlRycaRLr+2ESKYnXGTjBAn4wQ8UtR8s= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 538313858D29 for ; Mon, 22 Mar 2021 03:40:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 538313858D29 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 12M3eCAq002755 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 21 Mar 2021 23:40:17 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 12M3eCAq002755 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 47AC31E590; Sun, 21 Mar 2021 23:40:12 -0400 (EDT) Subject: Re: flag to know that we are compiling GDB for an arm target To: Zied Guermazi , "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> Message-ID: <0f6dc0a0-ad67-5247-34a1-8b22f41087ca@polymtl.ca> Date: Sun, 21 Mar 2021 23:40:11 -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: <4d77ba55-5ca6-4b44-2cc7-ecbb37ff26b6@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 03:40:12 +0000 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: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces@sourceware.org Sender: "Gdb" 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