public inbox for
 help / color / mirror / Atom feed
From: Simon Marchi <>
To: Torbjorn SVENSSON <>,
Cc:,, Yvan Roux <>
Subject: Re: [PATCH v3 1/2] gdb: dwarf2 generic implementation for caching function data
Date: Fri, 20 Jan 2023 12:28:53 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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


  reply	other threads:[~2023-01-20 17:28 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 ` [PATCH v3 1/2] gdb: dwarf2 generic implementation for caching function data Simon Marchi
2023-01-20 14:12   ` Torbjorn SVENSSON
2023-01-20 17:28     ` Simon Marchi [this message]
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).