From: Namhyung Kim <namhyung@kernel.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: "Ian Rogers" <irogers@google.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
"Jiri Olsa" <jolsa@kernel.org>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Kan Liang" <kan.liang@linux.intel.com>,
"John Garry" <john.g.garry@oracle.com>,
"Will Deacon" <will@kernel.org>,
"James Clark" <james.clark@linaro.org>,
"Mike Leach" <mike.leach@linaro.org>,
"Leo Yan" <leo.yan@linux.dev>, guoren <guoren@kernel.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Charlie Jenkins" <charlie@rivosinc.com>,
"Bibo Mao" <maobibo@loongson.cn>,
"Huacai Chen" <chenhuacai@kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Björn Töpel" <bjorn@rivosinc.com>,
"Howard Chu" <howardchu95@gmail.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
linux-riscv@lists.infradead.org, "Arnd Bergmann" <arnd@arndb.de>
Subject: Re: [PATCH v5 09/11] perf syscalltbl: Use lookup table containing multiple architectures
Date: Thu, 13 Mar 2025 12:55:56 -0700 [thread overview]
Message-ID: <Z9M4TIY9HstTLzNs@google.com> (raw)
In-Reply-To: <Z9MwQJ5bRu6-N43w@x1>
On Thu, Mar 13, 2025 at 04:21:36PM -0300, Arnaldo Carvalho de Melo wrote:
> On Fri, Mar 07, 2025 at 04:32:07PM -0800, Ian Rogers wrote:
> > Switch to use the lookup table containing all architectures rather
> > than tables matching the perf binary.
> >
> > This fixes perf trace when executed on a 32-bit i386 binary on an
> > x86-64 machine. Note in the following the system call names of the
> > 32-bit i386 binary as seen by an x86-64 perf.
> >
>
> Reproduced the results here:
>
> root@number:/home/acme/c# file faccessat2
> faccessat2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=8dafcc1549658d57248dce883e8ec7eea3d6e8a5, for GNU/Linux 3.2.0, not stripped
> root@number:/home/acme/c#
>
> root@number:/home/acme/c# strace ./faccessat2 |& head
> execve("./faccessat2", ["./faccessat2"], 0x7ffce63265e0 /* 39 vars */) = 0
> [ Process PID=2552445 runs in 32 bit mode. ]
> brk(NULL) = 0x849a000
> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fb3000
> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_ALL|STATX_MNT_ID|STATX_SUBVOL, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=85091, ...}) = 0
> mmap2(NULL, 85091, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f9e000
> close(3) = 0
> openat(AT_FDCWD, "/lib/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> root@number:/home/acme/c#
>
> Before:
>
> root@number:/home/acme/c# perf trace ./faccessat2 |& head
> faccessat2(123, (null), X_OK, AT_EACCESS | AT_SYMLINK_NOFOLLOW) = -1
> ? ( ): faccessat2/2552543 ... [continued]: munmap()) = 0
> 0.024 ( 0.002 ms): faccessat2/2552543 recvfrom(ubuf: 0x2, size: 4159848428, flags: DONTROUTE|CTRUNC|TRUNC|DONTWAIT|EOR|WAITALL|FIN|SYN|CONFIRM|RST|ERRQUEUE|SOCK_DEVMEM|ZEROCOPY|FASTOPEN|CMSG_CLOEXEC|0x91f20000, addr: 0xe30, addr_len: 0xffcda98c) = 138993664
> 0.047 ( 0.006 ms): faccessat2/2552543 lgetxattr(name: "", value: 0x3, size: 34) = 4159602688
> 0.063 ( 0.003 ms): faccessat2/2552543 dup2(oldfd: -135160188, newfd: 4) = -1 ENOENT (No such file or directory)
> 0.071 ( 0.023 ms): faccessat2/2552543 preadv(fd: 4294967196, vec: 0xf7f16420, vlen: 557056, pos_h: 4159848428) = 3
> 0.098 ( 0.004 ms): faccessat2/2552543 lgetxattr(name: "", value: 0x1, size: 2) = 4159516672
> 0.104 ( 0.001 ms): faccessat2/2552543 lstat(filename: "", statbuf: 0x14c63) = 0
> 0.114 ( 0.004 ms): faccessat2/2552543 preadv(fd: 4294967196, vec: 0xf7ee8380, vlen: 557056, pos_h: 4159848428) = 3
> 0.118 ( 0.002 ms): faccessat2/2552543 close(fd: 3) = 512
> root@number:/home/acme/c#
>
> After:
>
> root@number:/home/acme/c# perf trace ./faccessat2 |& head
> faccessat2(123, (null), X_OK, AT_EACCESS | AT_SYMLINK_NOFOLLOW) = -1
> sh: line 1: perf-read-vdso32: command not found
> ? ( ): faccessat2/2556897 ... [continued]: execve()) = 0
> 0.028 ( 0.002 ms): faccessat2/2556897 brk() = 0x8fe4000
> 0.068 ( 0.003 ms): faccessat2/2556897 access(filename: 0xf7ff2e84, mode: R) = -1 ENOENT (No such file or directory)
> 0.080 ( 0.005 ms): faccessat2/2556897 openat(dfd: CWD, filename: "/etc/ld.so.cache", flags: RDONLY|CLOEXEC|LARGEFILE) = 3
> 0.094 ( 0.001 ms): faccessat2/2556897 close(fd: 3) = 0
> 0.103 ( 0.003 ms): faccessat2/2556897 openat(dfd: CWD, filename: "/lib/libc.so.6", flags: RDONLY|CLOEXEC|LARGEFILE) = 3
> 0.108 ( 0.002 ms): faccessat2/2556897 read(fd: 3, buf: 0xffdd84b0, count: 512) = 512
> 0.216 ( 0.001 ms): faccessat2/2556897 close(fd: 3) = 0
> root@number:/home/acme/c#
>
> And interestingly the openat syscall got its contents obtained via the
> BPF augmenter... better to test this more thoroughly, but I think it
> should come after this series lands.
Right, I don't see the filename in openat() in my tests.
openat() is 295 on i386 and that's preadv() on x86_64 so BPF won't try
to augment the argument. I wonder how it can get the filename. But
anyway we can take a look later.
Thanks,
Namhyung
WARNING: multiple messages have this Message-ID (diff)
From: Namhyung Kim <namhyung@kernel.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: "Ian Rogers" <irogers@google.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Mark Rutland" <mark.rutland@arm.com>,
"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
"Jiri Olsa" <jolsa@kernel.org>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"Kan Liang" <kan.liang@linux.intel.com>,
"John Garry" <john.g.garry@oracle.com>,
"Will Deacon" <will@kernel.org>,
"James Clark" <james.clark@linaro.org>,
"Mike Leach" <mike.leach@linaro.org>,
"Leo Yan" <leo.yan@linux.dev>, guoren <guoren@kernel.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Charlie Jenkins" <charlie@rivosinc.com>,
"Bibo Mao" <maobibo@loongson.cn>,
"Huacai Chen" <chenhuacai@kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Björn Töpel" <bjorn@rivosinc.com>,
"Howard Chu" <howardchu95@gmail.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
linux-riscv@lists.infradead.org, "Arnd Bergmann" <arnd@arndb.de>
Subject: Re: [PATCH v5 09/11] perf syscalltbl: Use lookup table containing multiple architectures
Date: Thu, 13 Mar 2025 12:55:56 -0700 [thread overview]
Message-ID: <Z9M4TIY9HstTLzNs@google.com> (raw)
In-Reply-To: <Z9MwQJ5bRu6-N43w@x1>
On Thu, Mar 13, 2025 at 04:21:36PM -0300, Arnaldo Carvalho de Melo wrote:
> On Fri, Mar 07, 2025 at 04:32:07PM -0800, Ian Rogers wrote:
> > Switch to use the lookup table containing all architectures rather
> > than tables matching the perf binary.
> >
> > This fixes perf trace when executed on a 32-bit i386 binary on an
> > x86-64 machine. Note in the following the system call names of the
> > 32-bit i386 binary as seen by an x86-64 perf.
> >
>
> Reproduced the results here:
>
> root@number:/home/acme/c# file faccessat2
> faccessat2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, BuildID[sha1]=8dafcc1549658d57248dce883e8ec7eea3d6e8a5, for GNU/Linux 3.2.0, not stripped
> root@number:/home/acme/c#
>
> root@number:/home/acme/c# strace ./faccessat2 |& head
> execve("./faccessat2", ["./faccessat2"], 0x7ffce63265e0 /* 39 vars */) = 0
> [ Process PID=2552445 runs in 32 bit mode. ]
> brk(NULL) = 0x849a000
> mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf7fb3000
> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> statx(3, "", AT_STATX_SYNC_AS_STAT|AT_NO_AUTOMOUNT|AT_EMPTY_PATH, STATX_BASIC_STATS, {stx_mask=STATX_ALL|STATX_MNT_ID|STATX_SUBVOL, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=85091, ...}) = 0
> mmap2(NULL, 85091, PROT_READ, MAP_PRIVATE, 3, 0) = 0xf7f9e000
> close(3) = 0
> openat(AT_FDCWD, "/lib/libc.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
> root@number:/home/acme/c#
>
> Before:
>
> root@number:/home/acme/c# perf trace ./faccessat2 |& head
> faccessat2(123, (null), X_OK, AT_EACCESS | AT_SYMLINK_NOFOLLOW) = -1
> ? ( ): faccessat2/2552543 ... [continued]: munmap()) = 0
> 0.024 ( 0.002 ms): faccessat2/2552543 recvfrom(ubuf: 0x2, size: 4159848428, flags: DONTROUTE|CTRUNC|TRUNC|DONTWAIT|EOR|WAITALL|FIN|SYN|CONFIRM|RST|ERRQUEUE|SOCK_DEVMEM|ZEROCOPY|FASTOPEN|CMSG_CLOEXEC|0x91f20000, addr: 0xe30, addr_len: 0xffcda98c) = 138993664
> 0.047 ( 0.006 ms): faccessat2/2552543 lgetxattr(name: "", value: 0x3, size: 34) = 4159602688
> 0.063 ( 0.003 ms): faccessat2/2552543 dup2(oldfd: -135160188, newfd: 4) = -1 ENOENT (No such file or directory)
> 0.071 ( 0.023 ms): faccessat2/2552543 preadv(fd: 4294967196, vec: 0xf7f16420, vlen: 557056, pos_h: 4159848428) = 3
> 0.098 ( 0.004 ms): faccessat2/2552543 lgetxattr(name: "", value: 0x1, size: 2) = 4159516672
> 0.104 ( 0.001 ms): faccessat2/2552543 lstat(filename: "", statbuf: 0x14c63) = 0
> 0.114 ( 0.004 ms): faccessat2/2552543 preadv(fd: 4294967196, vec: 0xf7ee8380, vlen: 557056, pos_h: 4159848428) = 3
> 0.118 ( 0.002 ms): faccessat2/2552543 close(fd: 3) = 512
> root@number:/home/acme/c#
>
> After:
>
> root@number:/home/acme/c# perf trace ./faccessat2 |& head
> faccessat2(123, (null), X_OK, AT_EACCESS | AT_SYMLINK_NOFOLLOW) = -1
> sh: line 1: perf-read-vdso32: command not found
> ? ( ): faccessat2/2556897 ... [continued]: execve()) = 0
> 0.028 ( 0.002 ms): faccessat2/2556897 brk() = 0x8fe4000
> 0.068 ( 0.003 ms): faccessat2/2556897 access(filename: 0xf7ff2e84, mode: R) = -1 ENOENT (No such file or directory)
> 0.080 ( 0.005 ms): faccessat2/2556897 openat(dfd: CWD, filename: "/etc/ld.so.cache", flags: RDONLY|CLOEXEC|LARGEFILE) = 3
> 0.094 ( 0.001 ms): faccessat2/2556897 close(fd: 3) = 0
> 0.103 ( 0.003 ms): faccessat2/2556897 openat(dfd: CWD, filename: "/lib/libc.so.6", flags: RDONLY|CLOEXEC|LARGEFILE) = 3
> 0.108 ( 0.002 ms): faccessat2/2556897 read(fd: 3, buf: 0xffdd84b0, count: 512) = 512
> 0.216 ( 0.001 ms): faccessat2/2556897 close(fd: 3) = 0
> root@number:/home/acme/c#
>
> And interestingly the openat syscall got its contents obtained via the
> BPF augmenter... better to test this more thoroughly, but I think it
> should come after this series lands.
Right, I don't see the filename in openat() in my tests.
openat() is 295 on i386 and that's preadv() on x86_64 so BPF won't try
to augment the argument. I wonder how it can get the filename. But
anyway we can take a look later.
Thanks,
Namhyung
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-03-13 19:57 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-08 0:31 [PATCH v5 00/11] perf: Support multiple system call tables in the build Ian Rogers
2025-03-08 0:31 ` Ian Rogers
2025-03-08 0:31 ` [PATCH v5 01/11] perf dso: Move libunwind dso_data variables into ifdef Ian Rogers
2025-03-08 0:31 ` Ian Rogers
2025-03-08 0:32 ` [PATCH v5 02/11] perf dso: kernel-doc for enum dso_binary_type Ian Rogers
2025-03-08 0:32 ` Ian Rogers
2025-03-08 0:32 ` [PATCH v5 03/11] perf syscalltbl: Remove syscall_table.h Ian Rogers
2025-03-08 0:32 ` Ian Rogers
2025-03-08 0:32 ` [PATCH v5 04/11] perf trace: Reorganize syscalls Ian Rogers
2025-03-08 0:32 ` Ian Rogers
2025-03-08 0:32 ` [PATCH v5 05/11] perf syscalltbl: Remove struct syscalltbl Ian Rogers
2025-03-08 0:32 ` Ian Rogers
2025-03-08 0:32 ` [PATCH v5 06/11] perf dso: Add support for reading the e_machine type for a dso Ian Rogers
2025-03-08 0:32 ` Ian Rogers
2025-03-12 17:57 ` Arnaldo Carvalho de Melo
2025-03-12 17:57 ` Arnaldo Carvalho de Melo
2025-03-08 0:32 ` [PATCH v5 07/11] perf thread: Add support for reading the e_machine type for a thread Ian Rogers
2025-03-08 0:32 ` Ian Rogers
2025-03-08 0:32 ` [PATCH v5 08/11] perf trace beauty: Add syscalltbl.sh generating all system call tables Ian Rogers
2025-03-08 0:32 ` Ian Rogers
2025-03-08 0:32 ` [PATCH v5 09/11] perf syscalltbl: Use lookup table containing multiple architectures Ian Rogers
2025-03-08 0:32 ` Ian Rogers
2025-03-13 19:21 ` Arnaldo Carvalho de Melo
2025-03-13 19:21 ` Arnaldo Carvalho de Melo
2025-03-13 19:55 ` Namhyung Kim [this message]
2025-03-13 19:55 ` Namhyung Kim
2025-03-08 0:32 ` [PATCH v5 10/11] perf build: Remove Makefile.syscalls Ian Rogers
2025-03-08 0:32 ` Ian Rogers
2025-03-08 0:32 ` [PATCH v5 11/11] perf syscalltbl: Mask off ABI type for MIPS system calls Ian Rogers
2025-03-08 0:32 ` Ian Rogers
2025-03-13 7:11 ` [PATCH v5 00/11] perf: Support multiple system call tables in the build Namhyung Kim
2025-03-13 7:11 ` Namhyung Kim
2025-03-13 19:49 ` Arnaldo Carvalho de Melo
2025-03-13 19:49 ` Arnaldo Carvalho de Melo
2025-03-13 20:20 ` Arnaldo Carvalho de Melo
2025-03-13 20:20 ` Arnaldo Carvalho de Melo
2025-03-13 20:47 ` Arnaldo Carvalho de Melo
2025-03-13 20:47 ` Arnaldo Carvalho de Melo
2025-03-14 5:45 ` Namhyung Kim
2025-03-14 5:45 ` Namhyung Kim
2025-03-14 17:10 ` Arnaldo Carvalho de Melo
2025-03-14 17:10 ` Arnaldo Carvalho de Melo
2025-03-14 17:26 ` Arnaldo Carvalho de Melo
2025-03-14 17:26 ` Arnaldo Carvalho de Melo
2025-03-14 20:48 ` Arnaldo Carvalho de Melo
2025-03-14 20:48 ` Arnaldo Carvalho de Melo
2025-03-15 23:02 ` Namhyung Kim
2025-03-15 23:02 ` Namhyung Kim
2025-03-17 15:01 ` Ian Rogers
2025-03-17 15:01 ` Ian Rogers
2025-03-17 20:48 ` Arnaldo Carvalho de Melo
2025-03-17 20:48 ` Arnaldo Carvalho de Melo
2025-03-17 21:19 ` Arnaldo Carvalho de Melo
2025-03-17 21:19 ` Arnaldo Carvalho de Melo
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=Z9M4TIY9HstTLzNs@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=bjorn@rivosinc.com \
--cc=catalin.marinas@arm.com \
--cc=charlie@rivosinc.com \
--cc=chenhuacai@kernel.org \
--cc=guoren@kernel.org \
--cc=howardchu95@gmail.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jirislaby@kernel.org \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=leo.yan@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=maobibo@loongson.cn \
--cc=mark.rutland@arm.com \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=will@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.