From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id nwqrB3G7oGOFigUAWB0awg (envelope-from ) for ; Mon, 19 Dec 2022 14:28:49 -0500 Received: by simark.ca (Postfix, from userid 112) id 0D9BD1E222; Mon, 19 Dec 2022 14:28:49 -0500 (EST) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=eIUKCkEL; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-7.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 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 731111E0D3 for ; Mon, 19 Dec 2022 14:28:48 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 88192385840A for ; Mon, 19 Dec 2022 19:28:46 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 88192385840A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1671478126; bh=BchKuEUuwOH0iLsdFNcoZzK/DKt/5KrA3XKSFiKibFM=; h=Date:Subject:To:CC:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=eIUKCkELB4VErgvNO3sEhFGz+1E6u+erhaP1LNWr5xl5aakIaMd+mU6NmG2sDpTPX TD9SNSvqYUsu8GGS+5LefU7E8gcVuIpU3e2OFyozQmIxczxZ9fZSr/SWMXlhAq+HiC bwUI2PYGsnmxn8nIZ8+Fyhih2owxY4mDX9lOMxwA= Received: from mx07-00178001.pphosted.com (mx07-00178001.pphosted.com [185.132.182.106]) by sourceware.org (Postfix) with ESMTPS id DA9A73858410 for ; Mon, 19 Dec 2022 19:28:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DA9A73858410 Received: from pps.filterd (m0241204.ppops.net [127.0.0.1]) by mx07-00178001.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2BJIVh9O026486; Mon, 19 Dec 2022 20:28:22 +0100 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 3mh605bt8u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Dec 2022 20:28:22 +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 0A16610002A; Mon, 19 Dec 2022 20:28:18 +0100 (CET) Received: from Webmail-eu.st.com (shfdag1node3.st.com [10.75.129.71]) by euls16034.sgp.st.com (STMicroelectronics) with ESMTP id EEF202C41E1; Mon, 19 Dec 2022 20:28:17 +0100 (CET) Received: from [10.252.5.234] (10.252.5.234) 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; Mon, 19 Dec 2022 20:28:15 +0100 Message-ID: <6dfda131-1ed2-01a7-9ce0-ce5650cd22aa@foss.st.com> Date: Mon, 19 Dec 2022 20:28:14 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: [PING] [PATCH v2 3/4] gdb: dwarf2 generic implementation for caching function data Content-Language: en-US To: Luis Machado , CC: , Yvan Roux References: <20221118155252.113476-1-torbjorn.svensson@foss.st.com> <20221118155252.113476-4-torbjorn.svensson@foss.st.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.252.5.234] 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.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-19_01,2022-12-15_02,2022-06-22_01 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Torbjorn SVENSSON via Gdb-patches Reply-To: Torbjorn SVENSSON Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Ping! :) Can someone (Simon?, Andrew?, Pedro?, Joel?) take a look at the proposed patch? I would like to conclude something for the GDB13 release... Kind regards, Torbjörn On 2022-11-21 22:16, Luis Machado wrote: > Hi, > > On 11/18/22 15:52, Torbjörn SVENSSON wrote: >> When there is no dwarf2 data for a register, a function can be called >> to provide the value of this register.  In some situations, it might >> not be trivial to determine the value to return and it would cause a >> performance bottleneck to do the computation each time. >> >> This patch allows the called function to have a "cache" object that it >> can use to store some metadata between calls to reduce the performance >> impact of the complex logic. >> >> The cache object is unique for each function and frame, so if there are >> more than one function pointer stored in the dwarf2_frame_cache->reg >> array, then the appropriate pointer will be supplied (the type is not >> known by the dwarf2 implementation). >> >> dwarf2_frame_get_fn_data can be used to retrieve the function unique >> cache object. >> dwarf2_frame_allocate_fn_data can be used to allocate and retrieve the >> function unqiue cache object. > > unqiue -> unique > >> >> Signed-off-by: Torbjörn SVENSSON >> Signed-off-by: Yvan Roux >> --- >>   gdb/dwarf2/frame.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++ >>   gdb/dwarf2/frame.h | 20 +++++++++++++++++-- >>   2 files changed, 66 insertions(+), 2 deletions(-) >> >> diff --git a/gdb/dwarf2/frame.c b/gdb/dwarf2/frame.c >> index 3f884abe1d5..bff3b706e7e 100644 >> --- a/gdb/dwarf2/frame.c >> +++ b/gdb/dwarf2/frame.c >> @@ -831,6 +831,14 @@ dwarf2_fetch_cfa_info (struct gdbarch *gdbarch, >> CORE_ADDR pc, >>   } >>   >> +struct dwarf2_frame_fn_data >> +{ >> +  struct value *(*fn) (frame_info_ptr this_frame, void **this_cache, >> +               int regnum); >> +  void *data; >> +  struct dwarf2_frame_fn_data* next; >> +}; >> + > > I'm wondering if we really need to have a function pointer here. Isn't > the cache supposed to be frame-wide and not > function-specific? > > If we don't need it, the cache just becomes an opaque data pointer. > >>   struct dwarf2_frame_cache >>   { >>     /* DWARF Call Frame Address.  */ >> @@ -862,6 +870,8 @@ struct dwarf2_frame_cache >>        dwarf2_tailcall_frame_unwind unwinder so this field does not >> apply for >>        them.  */ >>     void *tailcall_cache; >> + >> +  struct dwarf2_frame_fn_data *fn_data; >>   }; >>   static struct dwarf2_frame_cache * >> @@ -1221,6 +1231,44 @@ dwarf2_frame_prev_register (frame_info_ptr >> this_frame, void **this_cache, >>       } >>   } >> +void *dwarf2_frame_get_fn_data (frame_info_ptr this_frame, void >> **this_cache, >> +                fn_prev_register fn) >> +{ >> +  struct dwarf2_frame_fn_data *fn_data = nullptr; >> +  struct dwarf2_frame_cache *cache >> +    = dwarf2_frame_cache (this_frame, this_cache); >> + >> +  /* Find the object for the function.  */ >> +  for (fn_data = cache->fn_data; fn_data; fn_data = fn_data->next) >> +    if (fn_data->fn == fn) >> +      return fn_data->data; >> + >> +  return nullptr; >> +} >> + >> +void *dwarf2_frame_allocate_fn_data (frame_info_ptr this_frame, >> +                     void **this_cache, >> +                     fn_prev_register fn, unsigned long size) >> +{ >> +  struct dwarf2_frame_fn_data *fn_data = nullptr; >> +  struct dwarf2_frame_cache *cache >> +    = dwarf2_frame_cache (this_frame, this_cache); >> + >> +  /* First try to find an existing object.  */ >> +  void *data = dwarf2_frame_get_fn_data (this_frame, this_cache, fn); >> +  if (data) >> +    return data; >> + >> +  /* No object found, lets create a new instance.  */ >> +  fn_data = FRAME_OBSTACK_ZALLOC (struct dwarf2_frame_fn_data); >> +  fn_data->fn = fn; >> +  fn_data->data = frame_obstack_zalloc (size); >> +  fn_data->next = cache->fn_data; >> +  cache->fn_data = fn_data; >> + >> +  return fn_data->data; >> +} > > And if we only have a data pointer, we can return a reference to it > through the argument, and then DWARF can cache it. > > We could even have a destructor/cleanup that can get called once the > frames are destroyed. > >> + >>   /* Proxy for tailcall_frame_dealloc_cache for bottom frame of a >> virtual tail >>      call frames chain.  */ >> diff --git a/gdb/dwarf2/frame.h b/gdb/dwarf2/frame.h >> index 06c8a10c178..444afd9f8eb 100644 >> --- a/gdb/dwarf2/frame.h >> +++ b/gdb/dwarf2/frame.h >> @@ -66,6 +66,9 @@ enum dwarf2_frame_reg_rule >>   /* Register state.  */ >> +typedef struct value *(*fn_prev_register) (frame_info_ptr this_frame, >> +                       void **this_cache, int regnum); >> + >>   struct dwarf2_frame_state_reg >>   { >>     /* Each register save state can be described in terms of a CFA slot, >> @@ -78,8 +81,7 @@ struct dwarf2_frame_state_reg >>         const gdb_byte *start; >>         ULONGEST len; >>       } exp; >> -    struct value *(*fn) (frame_info_ptr this_frame, void **this_cache, >> -             int regnum); >> +    fn_prev_register fn; >>     } loc; >>     enum dwarf2_frame_reg_rule how; >>   }; >> @@ -262,4 +264,18 @@ extern int dwarf2_fetch_cfa_info (struct gdbarch >> *gdbarch, CORE_ADDR pc, >>                     const gdb_byte **cfa_start_out, >>                     const gdb_byte **cfa_end_out); >> + >> +/* Allocate a new instance of the function unique data.  */ >> + >> +extern void *dwarf2_frame_allocate_fn_data (frame_info_ptr this_frame, >> +                        void **this_cache, >> +                        fn_prev_register fn, >> +                        unsigned long size); >> + >> +/* Retrieve the function unique data for this frame.  */ >> + >> +extern void *dwarf2_frame_get_fn_data (frame_info_ptr this_frame, >> +                       void **this_cache, >> +                       fn_prev_register fn); >> + >>   #endif /* dwarf2-frame.h */ > > As we've discussed before, I think the cache idea is nice if we have to > deal with targets with multiple CFA's (in our case, we have either 4 > SP's or 2 SP's, plus aliases). > > DWARF doesn't seem to support this at the moment, and the function HOW > for DWARF is not smart enough to remember a previously-fetched value. So > it seems we have room > for some improvement, unless there is enough reason elsewhere about why > we shouldn't have a cache. > > It would be nice to have some opinions from others, so we can > potentially shape this in a way that makes it useful for the general case.