[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZvL8gAy07ekBJZ_H@google.com>
Date: Tue, 24 Sep 2024 10:53:04 -0700
From: Namhyung Kim <namhyung@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Ian Rogers <irogers@...gle.com>, Charlie Jenkins <charlie@...osinc.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Howard Chu <howardchu95@...il.com>,
David Abdurachmanov <davidlt@...osinc.com>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org
Subject: Re: [PATCH] perf syscalltbl: Add syscalltbl__id_at_idx() with no
syscall table support
On Tue, Sep 24, 2024 at 09:11:41AM -0700, Ian Rogers wrote:
> On Tue, Sep 24, 2024 at 8:26 AM Charlie Jenkins <charlie@...osinc.com> wrote:
> >
> > On Fri, Aug 30, 2024 at 09:30:50PM -0700, Charlie Jenkins wrote:
> > > When HAVE_SYSCALL_TABLE_SUPPORT is not defined, neither is
> > > syscalltbl__id_at_idx(). However, this function is expected to be
> > > defined when HAVE_BPF_SKEL is defined.
> > >
> > > Return -1 from syscalltbl__id_at_idx() to match the other functions when
> > > HAVE_SYSCALL_TABLE_SUPPORT is not defined.
> > >
> > > Without this, compiling perf on riscv when libtraceevents, libelf, and
> > > clang are available will cause the functions trying to call
> > > syscalltbl__id_at_idx() to be compiled. This results in the following
> > > error:
> > >
> > > /usr/bin/ld: perf-in.o: in function `.L0 ':
> > > builtin-trace.c:(.text+0x60b14): undefined reference to `syscalltbl__id_at_idx'
> > > /usr/bin/ld: builtin-trace.c:(.text+0x60c6c): undefined reference to `syscalltbl__id_at_idx'
> > > /usr/bin/ld: perf-in.o: in function `.L2564':
> > > builtin-trace.c:(.text+0x60cb6): undefined reference to `syscalltbl__id_at_idx'
> > > collect2: error: ld returned 1 exit status
> > > make[2]: *** [Makefile.perf:793: perf] Error 1
> > > make[1]: *** [Makefile.perf:290: sub-make] Error 2
> > > make: *** [Makefile:70: all] Error 2
> > > make: Leaving directory '/src/linux-6.11-rc5/tools/perf'
> > >
> > > This patch resolves this issue for all architectures which do not define
> > > HAVE_SYSCALL_TABLE_SUPPORT.
> > >
> > > $ ./perf trace -e syscalls:sys_enter_mmap --max-events=1 ls
> > > 0.000 ls/287 syscalls:sys_enter_mmap(__syscall_nr: 222, len: 9939, prot: READ, flags: PRIVATE, fd: 3)
> > >
> > > Signed-off-by: Charlie Jenkins <charlie@...osinc.com>
> > > Reported-by: David Abdurachmanov <davidlt@...osinc.com>
> > > Suggested-by: David Abdurachmanov <davidlt@...osinc.com>
> > > Fixes: 7a2fb5619cc1 ("perf trace: Fix iteration of syscall ids in syscalltbl->entries")
> > > ---
> > > tools/perf/util/syscalltbl.c | 5 +++++
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/tools/perf/util/syscalltbl.c b/tools/perf/util/syscalltbl.c
> > > index 0dd26b991b3f..12654460428f 100644
> > > --- a/tools/perf/util/syscalltbl.c
> > > +++ b/tools/perf/util/syscalltbl.c
> > > @@ -188,4 +188,9 @@ int syscalltbl__strglobmatch_first(struct syscalltbl *tbl, const char *syscall_g
> > > {
> > > return syscalltbl__strglobmatch_next(tbl, syscall_glob, idx);
> > > }
> > > +
> > > +int syscalltbl__id_at_idx(struct syscalltbl *tbl __always_unused, int idx __always_unused)
> > > +{
> > > + return -1;
> > > +}
> > > #endif /* HAVE_SYSCALL_TABLE_SUPPORT */
> > >
> > > ---
> > > base-commit: 985bf40edf4343dcb04c33f58b40b4a85c1776d4
> > > change-id: 20240830-perf_syscalltbl_fix-4f586221795e
> > > --
> > > - Charlie
> > >
> >
> > Can this please be picked up? Compilation on riscv (along with any of
> > the other architectures that don't have syscall table support) is
> > broken. The long term solution is to add support for the syscall table
> > on riscv. I will send out a patch for that, but in the meantime it would
> > be great to have this in the tree.
>
> I thought something had been done:
> https://lore.kernel.org/lkml/739001a4-4df1-4dec-a141-926c78c5c07e@kernel.org/
> Not sure what's happened.
Hi Arnaldo, can you clarify what's going on here?
Thanks,
Namhyung
Powered by blists - more mailing lists