On Tue, Feb 11, 2025 at 9:53 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Tue, Feb 11, 2025, at 18:24, Ian Rogers wrote: > > On Tue, Feb 11, 2025 at 12:09 AM Arnd Bergmann <arnd@xxxxxxxx> 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, ...) Awesome, thanks for working on this! > >> > +#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. Thanks, adding linux-mips@xxxxxxxxxxxxxxx. Here is the original feedback for them for context: https://lore.kernel.org/lkml/07c5c3ad-5a6d-4eda-95f2-ed16e7504d4c@xxxxxxxxxxxxxxxx/ > >> > +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 Ack. > > 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. :-) I ate part of a cake intended as a goodwill gesture toward getting x32 into Android. Thanks, Ian
