From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: James Clark <james.clark@linaro.org>
Cc: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
Namhyung Kim <namhyung@kernel.org>,
Howard Chu <howardchu95@gmail.com>,
Alan Maguire <alan.maguire@oracle.com>,
Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Jiri Olsa <jolsa@kernel.org>,
Kan Liang <kan.liang@linux.intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-perf-users <linux-perf-users@vger.kernel.org>
Subject: Re: [PATCH 1/1] perf build: Require at least clang 16.0.6 to build BPF skeletons
Date: Fri, 11 Oct 2024 16:06:10 -0300 [thread overview]
Message-ID: <Zwl3IsgE3drp7mLo@x1> (raw)
In-Reply-To: <bcf50648-3c7e-4513-8717-0d14492c53b9@linaro.org>
On Thu, Oct 10, 2024 at 10:00:41AM +0100, James Clark wrote:
>
>
> On 10/10/2024 2:20 am, Arnaldo Carvalho de Melo wrote:
> > On Wed, Oct 9, 2024, 10:01 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > > On Tue, Oct 08, 2024 at 12:27:24AM -0700, Howard Chu wrote:
> > > > Hi Alan, Arnaldo and James,
> > > >
> > > > This problem was solved in [PATCH 0/2] perf trace: Fix support for the
> > > > new BPF feature in clang 12 (Link:
> > > >
> > > https://lore.kernel.org/linux-perf-users/20241007051414.2995674-1-howardchu95@gmail.com/T/#t
> > > ),
> > > > sorry I forgot to cc you two.
> > > >
> > > > Alan's thought was correct. Thank you so much! :)
> > >
> > > It'd be great if any of you can test this change. Now I only have
> > > machines with clang 16.
> > >
> >
> > I'll test this tomorrow.
> >
> > - Arnaldo
> >
> > >
> > > Thanks,
> > > Namhyung
> > >
> > >
> >
>
> Tested with clang 15:
>
> $ sudo perf trace -e write --max-events=100 -- echo hello
>
> 0.000 ( 0.014 ms): echo/834165 write(fd: 1, buf: hello\10, count: 6)
>
> =
>
> Tested-by: James Clark <james.clark@linaro.org>
>
>
> Unrelated to this change, I noticed that with older clangs or with
> BUILD_BPF_SKEL=0 that commit b257fac12f38 ("perf trace: Pretty print buffer
> data") changes the buffer address to print nothing, and the '6' return value
> is missing. Not sure if this was intended or not:
>
> $ sudo perf trace -e write --max-events=100 -- echo hello
>
> Before:
> 0.000 ( 0.009 ms): echo/772951 write(fd: 1, buf: 0x58c415257440,
> count: 6) = 6
>
> After:
> 0.000 ( 0.009 ms): echo/760370 write(fd: 1, buf: , count: 6)
>
I noticed this with fedora:40, and bisected it to:
⬢[acme@toolbox perf-tools]$ git bisect good
b257fac12f38d7f503b932313d704cee21092350 is the first bad commit
commit b257fac12f38d7f503b932313d704cee21092350
Author: Howard Chu <howardchu95@gmail.com>
Date: Sun Aug 25 00:33:19 2024 +0800
perf trace: Pretty print buffer data
Define TRACE_AUG_MAX_BUF in trace_augment.h data, which is the maximum
buffer size we can augment. BPF will include this header too.
Print buffer in a way that's different than just printing a string, we
print all the control characters in \digits (such as \0 for null, and
\10 for newline, LF).
For character that has a bigger value than 127, we print the digits
instead of the character itself as well.
Committer notes:
Simplified the buffer scnprintf to avoid using multiple buffers as
discussed in the patch review thread.
We can't really all 'buf' args to SCA_BUF as we're collecting so far
just on the sys_enter path, so we would be printing the previous 'read'
arg buffer contents, not what the kernel puts there.
So instead of:
static int syscall_fmt__cmp(const void *name, const void *fmtp)
@@ -1987,8 +1989,6 @@ syscall_arg_fmt__init_array(struct syscall_arg_fmt *arg, struct tep_format_field
- else if (strstr(field->type, "char *") && strstr(field->name, "buf"))
- arg->scnprintf = SCA_BUF;
Do:
static const struct syscall_fmt syscall_fmts[] = {
+ { .name = "write", .errpid = true,
+ .arg = { [1] = { .scnprintf = SCA_BUF /* buf */, from_user = true, }, }, },
Signed-off-by: Howard Chu <howardchu95@gmail.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Ian Rogers <irogers@google.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Kan Liang <kan.liang@linux.intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Link: https://lore.kernel.org/r/20240815013626.935097-8-howardchu95@gmail.com
Link: https://lore.kernel.org/r/20240824163322.60796-6-howardchu95@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Just did a:
⬢[acme@toolbox perf-tools]$ git checkout b257fac12f38d7f503b932313d704cee21092350
Updating files: 100% (12326/12326), done.
Note: switching to 'b257fac12f38d7f503b932313d704cee21092350'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.
<SNIP>
HEAD is now at b257fac12f38d7f5 perf trace: Pretty print buffer
make clean + rebuild and the returns are gone, if I do:
⬢[acme@toolbox perf-tools]$ git checkout b257fac12f38d7f503b932313d704cee21092350^
Previous HEAD position was b257fac12f38d7f5 perf trace: Pretty print buffer data
HEAD is now at cb32035214b9a09d perf trace: Pretty print struct data
⬢[acme@toolbox perf-tools]$
clean + rebuild instead I get those returns back:
Now staring at it...
- Arnaldo
prev parent reply other threads:[~2024-10-11 19:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-11 12:24 [PATCH 1/1] perf build: Require at least clang 16.0.6 to build BPF skeletons Arnaldo Carvalho de Melo
2024-09-12 14:40 ` James Clark
2024-09-12 14:50 ` Arnaldo Carvalho de Melo
2024-09-12 15:00 ` James Clark
2024-09-13 10:20 ` James Clark
[not found] ` <CA+JHD936J-q0-7LANQ3aW2G-PEmFP8PnXQ-TF-AMs9MtrCqfew@mail.gmail.com>
2024-09-17 17:37 ` Howard Chu
2024-09-19 3:13 ` Howard Chu
2024-09-24 2:00 ` Howard Chu
2024-09-24 9:29 ` Alan Maguire
2024-09-24 18:45 ` Howard Chu
2024-10-08 7:27 ` Howard Chu
2024-10-10 1:01 ` Namhyung Kim
[not found] ` <CA+JHD93JgJL_4GJFcFUNu-FpNfFOoyDRJ7QuvO82M8G1EwM5pQ@mail.gmail.com>
2024-10-10 9:00 ` James Clark
2024-10-10 9:11 ` James Clark
2024-10-10 16:15 ` Namhyung Kim
2024-10-11 19:06 ` Arnaldo Carvalho de Melo [this message]
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=Zwl3IsgE3drp7mLo@x1 \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alan.maguire@oracle.com \
--cc=arnaldo.melo@gmail.com \
--cc=howardchu95@gmail.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=namhyung@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).