From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx07-00178001.pphosted.com (mx08-00178001.pphosted.com [91.207.212.93]) by sourceware.org (Postfix) with ESMTPS id 23AFF3858D28 for ; Wed, 25 Jan 2023 09:34:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 23AFF3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=foss.st.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=foss.st.com Received: from pps.filterd (m0046660.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 30P9Ed3G010714; Wed, 25 Jan 2023 10:34:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foss.st.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=selector1; bh=QAy3FfsXWAlh/P21ihRtOLyYQuyxtbCFJyGjZVm8aAY=; b=yx74cF28Z4scl4trUM84J4JlaUXsy4i3NwmxgkurfVtfCXGXcK3ZLh2PwSXezzFxMS0F 49WQW7y4BK+K7VqtPaRa96T77cW7+i1NBOK2PNwwbH+9qg4fkZ4yRRUG6CrjEm/4ae/8 JYB/fAQCo1q7ybvj6BCJR2sUoQVDXAyRBiJBFMyqJJH3knBVop355tHer77jZoDYi7Ro PEg5oU+rmcnTbTWX6NXEVREEhRbmq7AnQqyAu0O5/ojDPTOO3b4qw0AlsL9X/Mrxi1qO 34/SL2JMjG4bcZeeBbL6/fjXwubz04caXXjNwHSCT1ZGNvdm8kr4pL9Zo9cp+SYSMVoE yg== Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by mx07-00178001.pphosted.com (PPS) with ESMTPS id 3najxhcefb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Jan 2023 10:34:35 +0100 Received: from euls16034.sgp.st.com (euls16034.sgp.st.com [10.75.44.20]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 08AEF10002A; Wed, 25 Jan 2023 10:34:34 +0100 (CET) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id F192F212FB4; Wed, 25 Jan 2023 10:34:33 +0100 (CET) Received: from [10.252.16.216] (10.252.16.216) by SHFDAG1NODE3.st.com (10.75.129.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.13; Wed, 25 Jan 2023 10:34:33 +0100 Message-ID: <78ce4bb2-af59-02ba-9977-8273b8ac9efb@foss.st.com> Date: Wed, 25 Jan 2023 10:34:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v3 1/2] gdb: dwarf2 generic implementation for caching function data To: Simon Marchi , Luis Machado , CC: , Yvan Roux References: <20230119102948.3069226-1-torbjorn.svensson@foss.st.com> <1ca2f916-21be-1627-7cc8-50da1a773cb8@foss.st.com> <05b54824-e13d-da77-1244-39dc65af3056@simark.ca> <46bf0f45-6469-2d1d-f6c0-6ae528b749d3@arm.com> <5781991c-70fd-0219-8c0d-940d648ad9de@simark.ca> Content-Language: en-US From: Torbjorn SVENSSON In-Reply-To: <5781991c-70fd-0219-8c0d-940d648ad9de@simark.ca> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.252.16.216] X-ClientProxiedBy: EQNCAS1NODE3.st.com (10.75.129.80) To SHFDAG1NODE3.st.com (10.75.129.71) X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-01-25_04,2023-01-24_01,2022-06-22_01 X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2023-01-20 18:43, Simon Marchi wrote: >> Maybe not a solution for now, but can't we use something like the trad-frame structs to cache >> values/locations of registers for a given frame? > > It's true that it's very similar, but I don't immediately see how I > would use it in this case. The trad-frame stuff saves the info in its > own format, whereas here it would be nice to cache struct values > directly. And it wouldn't be optimal for trad-frame to cache values, > because we would end up allocating values that might not be needed in > the end. > > However, I see that trad-frame uses an array of size > gdbarch_num_cooked_regs. It would make sense to use that here too, > instead of a hash table, it makes the lookups O(1). > > Simon I think this is something that can be looked at later (GDB14?). My first impression is that an array of pointers to struct value might work. If the pointer is nullptr, then there is no cached value, otherwise the pointer could be returned directly. But lest think of this after GDB13.