On Mon, Jun 2, 2025 at 8:05 AM Ian Rogers <irog...@google.com> wrote:
>
> On Sat, May 31, 2025 at 11:20 AM Alexei Starovoitov
> <alexei.starovoi...@gmail.com> wrote:
> >
> > On Sat, May 31, 2025 at 12:20 AM Blake Jones <blakejo...@google.com> wrote:
> > >
> > > The BTF dumper code currently displays arrays of characters as just that -
> > > arrays, with each character formatted individually. Sometimes this is what
> > > makes sense, but it's nice to be able to treat that array as a string.
> > >
> > > This change adds a special case to the btf_dump functionality to allow
> > > arrays of single-byte integer values to be printed as character strings.
> > > Characters for which isprint() returns false are printed as hex-escaped
> > > values. This is enabled when the new ".print_strings" is set to 1 in the
> > > btf_dump_type_data_opts structure.
> > >
> > > As an example, here's what it looks like to dump the string "hello" using
> > > a few different field values for btf_dump_type_data_opts (.compact = 1):
> > >
> > > - .print_strings = 0, .skip_names = 0: (char[6])['h','e','l','l','o',]
> > > - .print_strings = 0, .skip_names = 1: ['h','e','l','l','o',]
> > > - .print_strings = 1, .skip_names = 0: (char[6])"hello"
> > > - .print_strings = 1, .skip_names = 1: "hello"
> > >
> > > Here's the string "h\xff", dumped with .compact = 1 and .skip_names = 1:
> > >
> > > - .print_strings = 0: ['h',-1,]
> > > - .print_strings = 1: "h\xff"
> > >
> > > Signed-off-by: Blake Jones <blakejo...@google.com>
> > > ---
> > > tools/lib/bpf/btf.h | 3 +-
> > > tools/lib/bpf/btf_dump.c | 51 ++++++++-
> > > .../selftests/bpf/prog_tests/btf_dump.c | 102 ++++++++++++++++++
> > > 3 files changed, 154 insertions(+), 2 deletions(-)
> >
> > Please split selftests vs main libbpf parts.
> >
> > > diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
> > > index 4392451d634b..be8e8e26d245 100644
> > > --- a/tools/lib/bpf/btf.h
> > > +++ b/tools/lib/bpf/btf.h
> > > @@ -326,9 +326,10 @@ struct btf_dump_type_data_opts {
> > > bool compact; /* no newlines/indentation */
> > > bool skip_names; /* skip member/type names */
> > > bool emit_zeroes; /* show 0-valued fields */
> > > + bool print_strings; /* print char arrays as strings */
> > > size_t :0;
> > > };
> > > -#define btf_dump_type_data_opts__last_field emit_zeroes
> > > +#define btf_dump_type_data_opts__last_field print_strings
> > >
> > > LIBBPF_API int
> > > btf_dump__dump_type_data(struct btf_dump *d, __u32 id,
> > > diff --git a/tools/lib/bpf/btf_dump.c b/tools/lib/bpf/btf_dump.c
> > > index 460c3e57fadb..a07dd5accdd8 100644
> > > --- a/tools/lib/bpf/btf_dump.c
> > > +++ b/tools/lib/bpf/btf_dump.c
> > > @@ -75,6 +75,7 @@ struct btf_dump_data {
> > > bool is_array_member;
> > > bool is_array_terminated;
> > > bool is_array_char;
> > > + bool print_strings;
> >
> > Looks useful, but make sure to add a feature detection
> > to perf, since it has to work with old and new libbpf.
>
> Just for clarity on this. We'll need a "libbpf-strings" feature like
> the existing "libbpf" one:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/build/feature/test-libbpf.c?h=perf-tools-next
>
> Currently these features are only used if perf is built with
> LIBBPF_DYNAMIC=1 as part of the build arguments (ie its not the
> default):
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/Makefile.config?h=perf-tools-next#n580
>
> If no suitable libbpf is detected then the build will error out. I
> guess if feature-libbpf is present but not feature-libbpf-strings then
> we'll need a perf #define so that the string feature won't cause
> perf's build to fail.
Yes. Something like this.
It will also allow libbpf and perf patches to land in parallel.
