From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 84C173858D1E for ; Fri, 20 Jan 2023 17:28:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 84C173858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 45E881E0D3; Fri, 20 Jan 2023 12:28:54 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1674235735; bh=lb1hjWE9hoigE3GF2wM56iHj1JdQDdmGYpNemHFiuP4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qXtND62QrSwOXHPCEOskUOVa3p52MMjLljzjG3beT3gaACxKzxa+PAesn5cU9qQ1d iGPunsRWamcLgkh/lzsZZxEsSZRCqooTEIqh6uUmHfitHsqjOyg5A5SJmXU3ADb8Aw XLymjCs9+9S+EOBi2AHObVnavcyro62ozP1k3Bdc= Message-ID: <05b54824-e13d-da77-1244-39dc65af3056@simark.ca> Date: Fri, 20 Jan 2023 12:28:53 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Subject: Re: [PATCH v3 1/2] gdb: dwarf2 generic implementation for caching function data Content-Language: en-US To: Torbjorn SVENSSON , gdb-patches@sourceware.org Cc: luis.machado@arm.com, tom@tromey.com, Yvan Roux References: <20230119102948.3069226-1-torbjorn.svensson@foss.st.com> <1ca2f916-21be-1627-7cc8-50da1a773cb8@foss.st.com> From: Simon Marchi In-Reply-To: <1ca2f916-21be-1627-7cc8-50da1a773cb8@foss.st.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,SPF_HELO_PASS,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: > I suppose a generic cache might be useful in the long run, but it > would have an impact on other code paths and I'm not comfortable of > doing this major change now. Doing this change would imply that almost > everything related to unwinding is impacted in one way or another and > I suppose we would need to test that. With the solution I proposed, > only Arm Cortex would be impacted and the scope for testing would be > rather small. I understand the feeling. It's impossible to test every change on every configuration. We do our best to understand the code and how the change will impact different configurations, but we also have to accept a certain level of risk that we will break something, otherwise we will never change / improve anything. More eyes on the code, more people testing regularly with different configurations and more configurations on the Buildbot can help mitigate that. > I'm also aiming to resolve this for GDB13, so doing this major change > is a bit late in the sprint, right? Indeed. Then I think it's fine to introduce what you have, and then we could replace it with a more general solution later. > If you have a better idea on how to cache everything, like in your 3 > ideas above, please don't hesitate do share the implementation. :) I imagine something simple. A hash table in frame_info or somewhere else, where frame_unwind_register_value would put values returned by `next_frame->unwind->prev_register`, which would be returned directly on subsequent calls. This makes the assumption that a given frame info object has the same unwinder throughout its lifetime, and that it will return the same register value throughout its lifetime. I don't know of any situation where that is not true. To keep the allocation / deallocation cost down, the hash tables could be allocated on the frame obstack. Simon