From: Tsukasa OI <research_trasio@irq.a4lg.com>
To: Tsukasa OI <research_trasio@irq.a4lg.com>,
Andrew Burgess <aburgess@redhat.com>,
Palmer Dabbelt <palmer@dabbelt.com>
Cc: gdb-patches@sourceware.org
Subject: [RFC PATCH 0/1] gdb/riscv: Cache per-BFD disassembler
Date: Sun, 9 Oct 2022 03:59:02 +0000 [thread overview]
Message-ID: <cover.1665287884.git.research_trasio@irq.a4lg.com> (raw)
Hello,
On RISC-V, calling the disassembler function (libopcodes) is not a small
cost. This is because riscv_get_disassembler function sets the default
architecture from given BFD's .riscv.attributes section. However, by
default, GDB calls this function for every instruction.
This commit replaces RISC-V's disassembler function and stop calling
riscv_get_disassembler function if current BFD has not changed.
It expects around 30-80% improvements on disassembling relatively large
chunk of RISC-V code but most of them will be obscured by a RISC-V
disassembler optimization the author is currently working on. Still, 3-5%
of performance improvements will remain (due to reduced BFD section reads).
[REQUEST FOR COMMENTS]
I'm confident that most of BFD contents won't change so dynamically on GDB
and caching itself is not a bad idea. Still, I'm not sure whether this
usage of "static" variables is okay.
I would like to hear your thoughts.
Thanks,
Tsukasa
Tsukasa OI (1):
gdb/riscv: Cache per-BFD disassembler
gdb/riscv-tdep.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
base-commit: c10a862f17847bc9c50d680c87b87dc51ae4b95e
--
2.34.1
next reply other threads:[~2022-10-09 3:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-09 3:59 Tsukasa OI [this message]
2022-10-09 3:59 ` [RFC PATCH 1/1] " Tsukasa OI
2022-10-14 18:39 ` Tom Tromey
2022-10-16 15:31 ` Tsukasa OI
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=cover.1665287884.git.research_trasio@irq.a4lg.com \
--to=research_trasio@irq.a4lg.com \
--cc=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=palmer@dabbelt.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).