public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
To: Luis Machado <luis.machado@arm.com>, <gdb-patches@sourceware.org>
Cc: <vanekt@volny.cz>, Yvan Roux <yvan.roux@foss.st.com>
Subject: [PING] [PATCH v2 3/4] gdb: dwarf2 generic implementation for caching function data
Date: Mon, 19 Dec 2022 20:28:14 +0100	[thread overview]
Message-ID: <6dfda131-1ed2-01a7-9ce0-ce5650cd22aa@foss.st.com> (raw)
In-Reply-To: <fc7b1963-1fc1-1fb9-aec6-5a1cc35e9b52@arm.com>

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 <torbjorn.svensson@foss.st.com>
>> Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
>> ---
>>   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,
>>   }
>>   \f
>> +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.



  parent reply	other threads:[~2022-12-19 19:28 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-18 15:52 [PATCH 0/4] v2 gdb/arm: Fixes for Cortex-M stack unwinding Torbjörn SVENSSON
2022-11-18 15:52 ` [PATCH v2 1/4] gdb/arm: Update active msp/psp when switching stack Torbjörn SVENSSON
2022-11-21 14:04   ` Luis Machado
2022-11-18 15:52 ` [PATCH v2 2/4] gdb/arm: Ensure that stack pointers are in sync Torbjörn SVENSSON
2022-11-21 14:04   ` Luis Machado
2022-11-18 15:52 ` [PATCH v2 3/4] gdb: dwarf2 generic implementation for caching function data Torbjörn SVENSSON
2022-11-18 16:01   ` Torbjorn SVENSSON
2022-12-20 21:04     ` Tom Tromey
2022-11-21 21:16   ` Luis Machado
2022-11-29 15:19     ` Torbjorn SVENSSON
2022-11-29 16:24       ` Tomas Vanek
2022-11-30 10:16         ` Torbjorn SVENSSON
2022-11-30 10:19           ` Luis Machado
2022-12-08  1:11           ` Luis Machado
2022-12-19 19:28     ` Torbjorn SVENSSON [this message]
2022-12-20 21:02   ` Tom Tromey
2022-12-28 16:16     ` Torbjorn SVENSSON
2023-01-05 20:53       ` Torbjorn SVENSSON
2023-01-14  6:54       ` Joel Brobecker
2023-01-18 18:47   ` Tom Tromey
2023-01-19 10:31     ` Torbjorn SVENSSON
2022-11-18 15:52 ` [PATCH v2 4/4] gdb/arm: Use new dwarf2 function cache Torbjörn SVENSSON
2022-11-21 21:04   ` Luis Machado
2022-11-29 15:19     ` Torbjorn SVENSSON

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6dfda131-1ed2-01a7-9ce0-ce5650cd22aa@foss.st.com \
    --to=torbjorn.svensson@foss.st.com \
    --cc=gdb-patches@sourceware.org \
    --cc=luis.machado@arm.com \
    --cc=vanekt@volny.cz \
    --cc=yvan.roux@foss.st.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).