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.
next prev parent 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).