public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>
To: Simon Marchi <simark@simark.ca>,
	Luis Machado <luis.machado@arm.com>, <gdb-patches@sourceware.org>
Cc: <tom@tromey.com>, Yvan Roux <yvan.roux@foss.st.com>
Subject: Re: [PATCH v3 1/2] gdb: dwarf2 generic implementation for caching function data
Date: Wed, 25 Jan 2023 10:34:32 +0100	[thread overview]
Message-ID: <78ce4bb2-af59-02ba-9977-8273b8ac9efb@foss.st.com> (raw)
In-Reply-To: <5781991c-70fd-0219-8c0d-940d648ad9de@simark.ca>



On 2023-01-20 18:43, Simon Marchi wrote:
>> Maybe not a solution for now, but can't we use something like the trad-frame structs to cache
>> values/locations of registers for a given frame?
> 
> It's true that it's very similar, but I don't immediately see how I
> would use it in this case.  The trad-frame stuff saves the info in its
> own format, whereas here it would be nice to cache struct values
> directly.  And it wouldn't be optimal for trad-frame to cache values,
> because we would end up allocating values that might not be needed in
> the end.
> 
> However, I see that trad-frame uses an array of size
> gdbarch_num_cooked_regs.  It would make sense to use that here too,
> instead of a hash table, it makes the lookups O(1).
> 
> Simon

I think this is something that can be looked at later (GDB14?).

My first impression is that an array of pointers to struct value might 
work. If the pointer is nullptr, then there is no cached value, 
otherwise the pointer could be returned directly. But lest think of this 
after GDB13.

  reply	other threads:[~2023-01-25  9:34 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
2023-01-20 17:33       ` Luis Machado
2023-01-20 17:43         ` Simon Marchi
2023-01-25  9:34           ` Torbjorn SVENSSON [this message]
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:
  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=78ce4bb2-af59-02ba-9977-8273b8ac9efb@foss.st.com \
    --to=torbjorn.svensson@foss.st.com \
    --cc=gdb-patches@sourceware.org \
    --cc=luis.machado@arm.com \
    --cc=simark@simark.ca \
    --cc=tom@tromey.com \
    --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).