On Mon, Jun 2, 2025 at 8:05 AM Ian Rogers irogers@google.com wrote:
On Sat, May 31, 2025 at 11:20 AM Alexei Starovoitov alexei.starovoitov@gmail.com wrote:
On Sat, May 31, 2025 at 12:20 AM Blake Jones blakejones@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 blakejones@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...
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...
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.