Message-Id: <0195f9a0-5198-4ee0-b4ff-ea7126dc8299@app.fastmail.com>
Date: Tue, 11 Feb 2025 18:53:14 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Ian Rogers" <irogers@...gle.com>,
 "Arnaldo Carvalho de Melo" <acme@...nel.org>,
 "Howard Chu" <howardchu95@...il.com>
Cc: "Peter Zijlstra" <peterz@...radead.org>,
 "Ingo Molnar" <mingo@...hat.com>, "Namhyung Kim" <namhyung@...nel.org>,
 "Mark Rutland" <mark.rutland@....com>,
 "Alexander Shishkin" <alexander.shishkin@...ux.intel.com>,
 "Jiri Olsa" <jolsa@...nel.org>,
 "Adrian Hunter" <adrian.hunter@...el.com>,
 "Kan Liang" <kan.liang@...ux.intel.com>,
 "John Garry" <john.g.garry@...cle.com>, "Will Deacon" <will@...nel.org>,
 "James Clark" <james.clark@...aro.org>,
 "Mike Leach" <mike.leach@...aro.org>, "Leo Yan" <leo.yan@...ux.dev>,
 guoren <guoren@...nel.org>, "Paul Walmsley" <paul.walmsley@...ive.com>,
 "Palmer Dabbelt" <palmer@...belt.com>,
 "Albert Ou" <aou@...s.berkeley.edu>,
 "Charlie Jenkins" <charlie@...osinc.com>,
 "Bibo Mao" <maobibo@...ngson.cn>, "Huacai Chen" <chenhuacai@...nel.org>,
 "Catalin Marinas" <catalin.marinas@....com>,
 "Jiri Slaby" <jirislaby@...nel.org>,
 Björn Töpel <bjorn@...osinc.com>,
 linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org,
 "linux-csky@...r.kernel.org" <linux-csky@...r.kernel.org>,
 linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 5/7] perf trace beauty: Add syscalltbl.sh generating all system
 call tables

On Tue, Feb 11, 2025, at 18:24, Ian Rogers wrote:
> On Tue, Feb 11, 2025 at 12:09 AM Arnd Bergmann <arnd@...db.de> wrote:
>> On Mon, Feb 10, 2025, at 17:51, Ian Rogers wrote:
>> > "$tools_dir/perf/arch/arm64/entry/syscalls/syscall_64.tbl" "$outfile"
>> > common,64,renameat,rlimit,memfd_secret EM_AARCH64
>> > +cat >> "$outfile" <<EOF
>> > +#endif // defined(ALL_SYSCALLTBL) || defined(__arm__) ||
>> > defined(__aarch64__)
>>
>> Hardcoding the set of ABIs in the middle of the script seems
>> too fragile to me, I'm worried that these get out of sync quickly.
>
> I agree, again this is carrying forward a behavior and at least after
> these changes the location is just one place. Do you have any
> suggestions on how to do better?

Not sure, but I have some patches that I was planning to send
that puts these into arch/*/kernel/Makefile.syscalls for all
architectures in a consistent way. Ideally we'd use the same
Makefile contents for tools/perf in order to trivially sync
them, but I'm also happy to hear other suggestions.

Your patches are currently ahead of mine, so I don't want to
hold you up. 

> Fwiw, I wonder a related problem/question that has come up primarily
> with Arnaldo and Howard is in having a way to determine system call
> argument types so that perf trace can pretty print them. For example,
> if via BTF it is found an argument is a "const char*" then it is
> assumed to be a string, but a "char *" is not as it may just be an out
> argument. There's a source for more information in the syzkaller
> project:
> https://github.com/google/syzkaller/blob/master/sys/linux/sys.txt
> Perhaps there's a way to generate this information from the Linux
> build and feed it into perf's build. It is out-of-scope for what I'm
> trying to do here, but I thought it worth a mention given my general
> ignorance on wider things.

Yes, this is also something I've been trying to work on. In particular
the calling conventions for 64-bit register arguments on 32-bit
targets need some help. My plan for this is to have a consistent
mapping of internal (sys_foo()) function names to argument lists,
instead of having some calls that are slightly different depending
on the architecture or ABI.

This should be in a machine-readable format so it can be parsed
not only by perf but also any other project that needs a list
(libc, gdb, qemu, strace, rust, ...)

>> > +#if defined(ALL_SYSCALLTBL) || defined(__mips__)
>> > +EOF
>> > +build_tables
>> > "$tools_dir/perf/arch/mips/entry/syscalls/syscall_n64.tbl" "$outfile"
>> > common,64,n64 EM_MIPS
>> > +cat >> "$outfile" <<EOF
>> > +#endif // defined(ALL_SYSCALLTBL) || defined(__mips__)
>>
>> What about n32/o32? The syscall tables are completely different here.
>
> So perf hasn't historically supported them and no one is asking for
> support. Generating more tables isn't the problem, but we need to have
> some way of determining which table to use for n32/o32. I see
> EF_MIPS_ABI_O32 and EF_MIPS_ABI_O64, so we could add support by
> extending the lookup of the table to be both of e_machine and e_flags.
> I'm less clear on choosing n32. That said, back in the 90s I was
> working to port MIPS code to Itanium via binary translation. Given now
> Itanium is obsolete, I'm not sure it is worth adding complexity for
> the sake of MIPS. I'm happy to do what others feel is best here, but
> my default position is just to carry what the existing behavior is
> forward.

I think the way it actually works on mips is that all syscalls are
allowed in any task and the actual number identifies both the
ABI and the syscall. In some variant, the same is true on arm
(oabi/eabi) and x86-64 (64/x32), but oabi and x32 are both too
obsolete to put much work into them.

There is still some interest in mips, maybe you can poke the
maintainers and see if someone is willing to help out since you
have done the bulk of the work already.

>> > +EOF
>> > +build_tables "$tools_dir/perf/arch/s390/entry/syscalls/syscall.tbl"
>> > "$outfile" common,64,renameat,rlimit,memfd_secret EM_S390
>> > +cat >> "$outfile" <<EOF
>> > +#endif // defined(ALL_SYSCALLTBL) || defined(__s390x__)
>>
>> This skips the 32-bit table, though I think that one is already
>> planned to be discontinued in the future.
>
> Thankfully we have awesome s390 devs on the mailing list, hopefully
> they'll shout out if I'm doing things wrong.

I also remembered that I had a patch to bring the s390 syscall.tbl
into the same format as the others, since the behavior is currently
a bit different for compat calls. I think there is also a chance
that they want to discontinue 32-bit mode entirely, given that
the last 32-bit machine was discontinued over 20 years ago, and
support for native 32-bit kernels got removed 10 years ago
after Debian 8 moved to 64 bit.

If they are confident that there are no more remaining users that
rely on 32-bit binaries, we could both save some work.

>> > +#if defined(ALL_SYSCALLTBL) || defined(__i386__) || defined(__x86_64__)
>> > +EOF
>> > +build_tables "$tools_dir/perf/arch/x86/entry/syscalls/syscall_32.tbl"
>> > "$outfile" common,32,i386 EM_386
>> > +build_tables "$tools_dir/perf/arch/x86/entry/syscalls/syscall_64.tbl"
>> > "$outfile" common,64 EM_X86_64
>> > +cat >> "$outfile" <<EOF
>> > +#endif // defined(ALL_SYSCALLTBL) || defined(__i386__) ||
>> > defined(__x86_64__)
>>
>> This misses the x32 table.
>
> Again I'm carrying forward a behavior. Would it be worth adding x32?

I would probably document it in the file as an intentional
omission, same as for arm oabi

> That said there is likely other context
> that I'm unaware of as I'm surprised x32 still exists.

There are a handful of people still testing it, and some still
using it, but I agree it completely failed to get enough
traction to be worth maintaining.

I view x32 (and the corresponding arm64 ilp32 mode that never
made it in) mostly as an exercise in benchmark(et)ing, since
it showed noticeably higher results in some versions of specint
and some compiler workloads, compared to both normal 32-bit and
64-bit modes. The time that we already wasted on maintaining
it must have long surpassed any such benefits though, so I
certainly don't want to waste more time on it.

     Arnd

Powered by blists - more mailing lists