Messages in this thread | | | Date | Fri, 25 Nov 2022 12:53:10 +0100 | From | Vincent Whitchurch <> | Subject | Re: [PATCH] perf arm64: Fix mksyscalltbl, don't lose syscalls due to sort -nu |
| |
On Tue, Dec 29, 2020 at 11:09:33AM +0800, Leo Yan wrote: > On Mon, Dec 28, 2020 at 03:39:41AM +0100, Hans-Peter Nilsson wrote: > > When using "sort -nu", arm64 syscalls were lost. That is, the > > io_setup syscall (number 0) and all but one (typically > > ftruncate; 64) of the syscalls that are defined symbolically > > (like "#define __NR_ftruncate __NR3264_ftruncate") at the point > > where "sort" is applied. > > > > This creation-of-syscalls.c-scheme is, judging from comments, > > copy-pasted from powerpc, and worked there because at the time, > > its tools/arch/powerpc/include/uapi/asm/unistd.h had *literals*, > > like "#define __NR_ftruncate 93". > > > > With sort being numeric and the non-numeric key effectively > > evaluating to 0, the sort option "-u" means these "duplicates" > > are removed. There's no need to remove syscall lines with > > duplicate numbers for arm64 because there are none, so let's fix > > that by just losing the "-u". Having the table numerically > > sorted on syscall-number for the rest of the syscalls looks > > nice, so keep the "-n". > > > > Signed-off-by: Hans-Peter Nilsson <hp@axis.com> > > Very good catching! I tested this patch with the commands: > > $ cd $LINUX_KERN > $ tools/perf/arch/arm64/entry/syscalls/mksyscalltbl \ > $ARM64_TOOLCHAIN_PATH/aarch64-linux-gnu-gcc \ > gcc tools tools/include/uapi/asm-generic/unistd.h > > It gives out complete syscall tables: > > $ diff /tmp/mksyscall_before.txt /tmp/mksyscall_after.txt > 1a2,4 > > [223] = "fadvise64", > > [25] = "fcntl", > > [44] = "fstatfs", > 2a6,11 > > [0] = "io_setup", > > [62] = "lseek", > > [222] = "mmap", > > [71] = "sendfile", > > [43] = "statfs", > > [45] = "truncate", > > Rather than dropping option "-u" for sort command, I googled and read > the manual of "sort", but cannot find other better method. So this > patch looks good for me: > > Reviewed-by: Leo Yan <leo.yan@linaro.org> > Tested-by: Leo Yan <leo.yan@linaro.org>
It looks like this patch was never applied? AFAICS it is still needed on current HEAD and it still applies cleanly.
| |