From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Charlie Jenkins <charlie@rivosinc.com>
Cc: Ian Rogers <irogers@google.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org
Subject: Re: [PATCH v2] tools: perf: tests: Fix code reading for riscv
Date: Wed, 18 Dec 2024 15:41:32 -0300 [thread overview]
Message-ID: <Z2MXXFhUzoQmW4xV@x1> (raw)
In-Reply-To: <Z2IXl5cuKQJInJb0@ghost>
On Tue, Dec 17, 2024 at 04:30:15PM -0800, Charlie Jenkins wrote:
> On Tue, Dec 17, 2024 at 04:18:32PM -0800, Ian Rogers wrote:
> > On Tue, Dec 17, 2024 at 3:52 PM Charlie Jenkins <charlie@rivosinc.com> wrote:
> > > After binutils commit e43d876 which was first included in binutils 2.41,
> > > riscv no longer supports dumping in the middle of instructions. Increase
> > > the objdump window by 2-bytes to ensure that any instruction that sits
> > > on the boundary of the specified stop-address is not cut in half.
> > > Signed-off-by: Charlie Jenkins <charlie@rivosinc.com>
> > Reviewed-by: Ian Rogers <irogers@google.com>
> > > A binutils patch has been sent as well to fix this in objdump [1].
> > > Link: https://sourceware.org/pipermail/binutils/2024-December/138139.html [1]
> > > Changes in v2:
> > > - Do objdump version detection at runtime (Ian)
> > > - Link to v1: https://lore.kernel.org/r/20241216-perf_fix_riscv_obj_reading-v1-0-b75962660a9b@rivosinc.com
> > > --- a/tools/perf/tests/code-reading.c
> > > @@ -183,9 +244,30 @@ static int read_via_objdump(const char *filename, u64 addr, void *buf,
> > > const char *fmt;
> > > FILE *f;
> > > int ret;
> > > + u64 stop_address = addr + len;
> > > +
> > > + if (IS_ENABLED(__riscv)) {
> > Not sure if there is a consistency issue here. Elsewhere we're just
> > using ifdef, such as:
> > https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/util/include/dwarf-regs.h?h=perf-tools-next#n69
> I don't have any strong feelings about that. I can change it to be an
> ifdef. On other lists I have been told to use IS_ENABLED whenever
> possible, but it's only a small difference.
Can't we just use uname here?
So that we don't use kconfig.h since its not used in tools/perf/ and
makes it looks like perf is in lockstep with the kernel source tree
version it was compiled from?
$ git grep kconfig.h tools/perf/
$
BTW, what would happen if I collected a perf.data file on x86_64 and
would read it in a RiscV machine with such a objdump version? The same
problem?
- Arnaldo
next prev parent reply other threads:[~2024-12-18 18:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-17 23:52 [PATCH v2] tools: perf: tests: Fix code reading for riscv Charlie Jenkins
2024-12-18 0:18 ` Ian Rogers
2024-12-18 0:30 ` Charlie Jenkins
2024-12-18 0:55 ` Ian Rogers
2024-12-18 18:41 ` Arnaldo Carvalho de Melo [this message]
2024-12-18 19:23 ` Ian Rogers
2024-12-18 21:02 ` Charlie Jenkins
2024-12-18 22:13 ` Ian Rogers
2024-12-18 22:32 ` Charlie Jenkins
2024-12-19 1:20 ` Ian Rogers
2024-12-19 1:52 ` Charlie Jenkins
2025-01-03 1:44 ` Charlie Jenkins
2025-01-03 16:51 ` Arnaldo Carvalho de Melo
2025-01-03 19:15 ` Charlie Jenkins
2024-12-18 20:57 ` Charlie Jenkins
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=Z2MXXFhUzoQmW4xV@x1 \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=aou@eecs.berkeley.edu \
--cc=charlie@rivosinc.com \
--cc=irogers@google.com \
--cc=jolsa@kernel.org \
--cc=justinstitt@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=namhyung@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
/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