linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alan Maguire <alan.maguire@oracle.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Kan Liang <kan.liang@linux.intel.com>,
	Clark Williams <williams@redhat.com>,
	linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	Howard Chu <howardchu95@gmail.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: Re: [PATCH RFC 0/2] Prep perf trace for a generic BPF+BTF pretty printer
Date: Mon, 9 Sep 2024 16:46:15 +0100	[thread overview]
Message-ID: <b3fa69b9-4acf-4a86-9ef6-be89036c2fa9@oracle.com> (raw)
In-Reply-To: <20240906195020.481841-1-acme@kernel.org>

On 06/09/2024 20:50, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo <acme@redhat.com>
> 
> Hi,
> 
> 	This is an attempt at paving the way for the remaining parts of
> Howard's work on this years GSoC to be merged, as we want to keep the
> existing pretty printers for the few structs we have, that have special
> characteristics (see the commit logs) while having the generic BPF + BTF
> collector/pretty printer, using the libbpf BPF dumper (see more ideas on
> the commit log on how to improve it, maybe even getting
> tools/perf/trace/beauty/ into tools/lib/beauty/ to get reused by
> libbpf).
>

hey Arnaldo

Absolutely, finding the common ground here would be great! I took a
quick look at some of the beautify scripts, and it struck me that some
of what's missing today - and what makes this hard - is that we don't
have easy access to numeric macro name -> value mappings for things like
arch-specific errno values (at least not without DWARF).

In another context, we've seen pain for BPF program writers who have to
cut+paste macro values into their BPF code.  We've sort of solved this
in a few specific cases by converting some values to enumerations. They
then get BTF representations, and can benefit from Compile Once - Run
Everywhere when the macro value is used in the BPF context.

But it seems to me that what both these problems suggest is that it
would be nice to more systematically represent numeric macro values such
that they would be more easily available. I talked a bit about this a
few years back at Plumbers for macros as a whole, but I wonder if a
tweak to pahole that does something like

1. check if a macro has a valid numeric representation;
2. if so, convert it to a singleton anonymous BTF enumerated type that
will not clash with the real macro name (so is safe to use when headers
containing that macro are also included)

This would allow BPF program writers to reference macro-defined flag
values and get the CO-RE benefits they get from enums and presence in a
generated vmlinux.h. It might also help here for beautify where you
could establish name-value mappings for things like arch-specific errnos.

We've been talking about having a loadable module of vmlinux BTF extras,
so it seems like numeric macro representations would be helpful there
too. What do you think? Thanks!

Alan


> 	I plan to work on the weekend to plugging his latest series on
> top of these patches so that we can get it merged in the next merge
> window.
> 
> 	Any comment/test is more than welcome,
> 
> - Arnaldo
> 
> Arnaldo Carvalho de Melo (2):
>   perf trace augmented_syscalls.bpf: Move the renameat augmenter to
>     renameat2, temporarily
>   perf trace: Use a common encoding for augmented arguments, with size +
>     error + payload
> 
>  tools/perf/trace/beauty/perf_event_open.c     |   2 +-
>  tools/perf/trace/beauty/sockaddr.c            |   2 +-
>  tools/perf/trace/beauty/timespec.c            |   2 +-
>  .../bpf_skel/augmented_raw_syscalls.bpf.c     | 108 +++++++++++-------
>  4 files changed, 68 insertions(+), 46 deletions(-)
> 

  parent reply	other threads:[~2024-09-09 15:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-06 19:50 [PATCH RFC 0/2] Prep perf trace for a generic BPF+BTF pretty printer Arnaldo Carvalho de Melo
2024-09-06 19:50 ` [PATCH 1/2] perf trace augmented_syscalls.bpf: Move the renameat augmenter to renameat2, temporarily Arnaldo Carvalho de Melo
2024-09-09 17:05   ` Ian Rogers
2024-09-09 22:14     ` Arnaldo Carvalho de Melo
2024-09-06 19:50 ` [PATCH 2/2] perf trace: Use a common encoding for augmented arguments, with size + error + payload Arnaldo Carvalho de Melo
2024-09-09 17:04   ` Ian Rogers
2024-09-09 15:46 ` Alan Maguire [this message]
2024-09-09 22:23   ` [PATCH RFC 0/2] Prep perf trace for a generic BPF+BTF pretty printer 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=b3fa69b9-4acf-4a86-9ef6-be89036c2fa9@oracle.com \
    --to=alan.maguire@oracle.com \
    --cc=acme@kernel.org \
    --cc=acme@redhat.com \
    --cc=adrian.hunter@intel.com \
    --cc=andrii@kernel.org \
    --cc=howardchu95@gmail.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.com \
    /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).