[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20241025132021.GB359792@e132581.arm.com>
Date: Fri, 25 Oct 2024 14:20:21 +0100
From: Leo Yan <leo.yan@....com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Jing Zhang <renyu.zj@...ux.alibaba.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Richter <tmricht@...ux.ibm.com>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
xueshuai@...ux.alibaba.com, zhuo.song@...ux.alibaba.com
Subject: Re: [PATCH] perf/tests: fix record+probe_libc_inet_pton test on
aarch64
On Sun, Oct 20, 2024 at 12:35:28PM +0100, Leo Yan wrote:
> Hi Namhyung, Jing,
>
> On Thu, Oct 17, 2024 at 03:12:36PM -0700, Namhyung Kim wrote:
> >
> > Hello,
> >
> > On Tue, Oct 15, 2024 at 03:53:27PM +0800, Jing Zhang wrote:
> > > Since commit 1f85d016768f ("perf test record+probe_libc_inet_pton: Fix
> > > call chain match on x86_64") remove function getaddrinfo() on expected
> > > file, the test failed on aarch64. On aarch64, function getaddrinfo()
> > > show up in the call chain.
> > >
> > > $perf script -i /tmp/perf.data.1PV
> > > ping 2588319 [125] 500119.122843: probe_libc:inet_pton: (ffff9a4f7410)
> > > ffff9a4f7410 __GI___inet_pton+0x0 (/usr/lib64/libc-2.32.so)
> > > ffff9a4c5f7c getaddrinfo+0xec (/usr/lib64/libc-2.32.so)
> > > aaaad6d32b38 [unknown] (/usr/bin/ping)
> >
> > I'm curious how other ARM folks don't see this. Does it depend on
> > something other?
>
> This test has several dependencies. E.g. libtraceevent and IPv6 (one
> of my machines skips the test due to lack IPv6 interface).
>
> This test is definitely a regression on Arm64 machine. I will go back to
> check why this test failure is missed in our CI. If have any update,
> will let you know.
>
> > Then can we make the line optional like we did on s390 recently?
>
> I verified two distros (one is libc-2.31 and another is libc-2.37), both of
> them have the symbol "getaddrinfo":
>
> Machine 1:
>
> # nm -D /usr/lib/aarch64-linux-gnu/libc-2.31.so | grep getaddrinfo
> 00000000000bdf58 T getaddrinfo
>
> Machine 2:
>
> # /usr/lib/aarch64-linux-gnu/libc.so.6
> GNU C Library (Debian GLIBC 2.37-16) stable release version 2.37.
>
> # nm -D /usr/lib/aarch64-linux-gnu/libc.so.6 | grep getaddrinfo
> 00000000000d4da4 T getaddrinfo@@GLIBC_2.17
> 0000000000114260 T getaddrinfo_a@@GLIBC_2.34
> 0000000000114260 T getaddrinfo_a@...BC_2.17
Update a bit for Arm64. Without this patch, we do see the test can pass on
Debian bookworm (with libc 2.36) but failed on older distros.
On the Debian bookworm, it prints out the log same as above. Seems to me,
these symbols with suffix "@GLIBC_2.x" are legacy functions for old libc
compatible but is not used by the new libc.
So we need to rule out the case for the symbol with suffix. Please check
if below change is suitable?
diff --git a/tools/perf/tests/shell/record+probe_libc_inet_pton.sh b/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
index f38c8ead0b03..2079c9375af5 100755
--- a/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
+++ b/tools/perf/tests/shell/record+probe_libc_inet_pton.sh
@@ -54,6 +54,11 @@ trace_libc_inet_pton_backtrace() {
;;
*)
eventattr='max-stack=3'
+ # The new version libc (e.g. libc 2.36) contains symbol getaddrinfo@@GLIBC_2.17
+ # which is not used. Do strick checking for 'getaddrinfo' without any suffix.
+ if nm -D $libc | grep -q 'getaddrinfo$'; then
+ echo "getaddrinfo\+0x[[:xdigit:]]+[[:space:]]\($libc\)$" >> $expected
+ fi
echo ".*(\+0x[[:xdigit:]]+|\[unknown\])[[:space:]]\(.*/bin/ping.*\)$" >> $expected
;;
esac
Thanks,
Leo
Powered by blists - more mailing lists