public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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


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