public inbox for
 help / color / mirror / Atom feed
From: Simon Marchi <>
To: "Torbjörn SVENSSON" <>,
Cc:,, Yvan Roux <>
Subject: Re: [PATCH v3 1/2] gdb: dwarf2 generic implementation for caching function data
Date: Thu, 19 Jan 2023 11:53:48 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 1/19/23 05:29, Torbjörn SVENSSON via Gdb-patches wrote:
> v2 -> v3:
> Addressed comments from Tom in
> ---
> 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 unique cache object.
> Signed-off-by: Torbjörn SVENSSON <>
> Signed-off-by: Yvan Roux <>


My main question is: this approach requires each custom prev_register
function to set up and manage its own cache.  Did you consider caching
values at a higher level?


 1. In dwarf2_frame_prev_register, just for DWARF2_FRAME_REG_FN
 2. In dwarf2_frame_prev_register, but for all kinds of registers
 3. In frame_unwind_register_value, which would cache all register values
    for all frames regardless of the unwinder

I don't know if other ways of unwinding would benefit that much from
caching, but I guess it wouldn't hurt.  For instance, evaluating DWARF
expressions is probably generally not super expensive, but it might
still benefit from getting cached.  And it would be nice to write the
caching code just once and have it work transparently for everything.

> @@ -262,4 +264,35 @@ 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.
> +
> +   The main purpose of this custom function data object is to allow caching the
> +   value of expensive lookups in the prev_register implementation.

I would replace "in the prev_register implementation" with "in
prev_register implementations".  There isn't only one prev_register
implementation AFAIK.


  parent reply	other threads:[~2023-01-19 16:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-19 10:29 Torbjörn SVENSSON
2023-01-19 10:29 ` [PATCH v3 2/2] gdb/arm: Use new dwarf2 function cache Torbjörn SVENSSON
2023-01-25 16:55   ` Luis Machado
2023-01-25 17:12     ` Simon Marchi
2023-01-25 20:15       ` Torbjorn SVENSSON
2023-01-19 16:53 ` Simon Marchi [this message]
2023-01-20 14:12   ` [PATCH v3 1/2] gdb: dwarf2 generic implementation for caching function data Torbjorn SVENSSON
2023-01-20 17:28     ` Simon Marchi
2023-01-20 17:33       ` Luis Machado
2023-01-20 17:43         ` Simon Marchi
2023-01-25  9:34           ` Torbjorn SVENSSON
2023-01-20 19:59 ` Tom Tromey
2023-01-25  9:39   ` Torbjorn SVENSSON
2023-01-25 16:11     ` Tom Tromey

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:

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

  git send-email \ \ \ \ \ \ \ \

* 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).