Hi Jiri,
On Wed, Jun 11, 2025 at 3:34 AM Jiri Olsa wrote:
> could this be used in bpftool map dump? ;-) I checked, but it looks like
> bpftool map dump is using something else to dump data.. I admit I haven't
> spent much on time that
I actually started this work by looking at bpftool's dumper,
When this mode is turned on, "emit_zeroes" and "compact" have no effect,
and embedded NUL characters always terminate printing of an array.
Signed-off-by: Blake Jones
---
.../selftests/bpf/prog_tests/btf_dump.c | 118 ++
1 file changed, 118 inserti
: ['h','e','l','l','o',]
- .emit_strings = 1, .skip_names = 0: (char[6])"hello"
- .emit_strings = 1, .skip_names = 1: "hello"
Here's the string "h\xff", dumped with .compact = 1 and .skip_names =
Hi Andrii,
On Tue, Jun 3, 2025 at 11:39 AM Andrii Nakryiko
wrote:
> > Good question. That E2BIG error would happen, for example, if we tried
> > to print the array "{ 'a', 'b', 'c' }" when the type was "char[4]".
>
> Exactly, data is truncated, we have to return E2BIG. But I think that
> is check
On Tue, Jun 3, 2025 at 6:18 AM Jiri Olsa wrote:
> > +static int btf_dump_string_data(struct btf_dump *d,
> > + const struct btf_type *t,
> > + __u32 id,
> > + const void *data)
> > +{
> > + const struct btf_arr
,'e','l','l','o',]
- .emit_strings = 1, .skip_names = 0: (char[6])"hello"
- .emit_strings = 1, .skip_names = 1: "hello"
Here's the string "h\xff", dumped with .compact = 1 and .skip_names =
Hi Andrii,
Thanks for your careful review.
On Mon, Jun 2, 2025 at 5:06 PM Andrii Nakryiko
wrote:
> > + bool print_strings; /* print char arrays as strings */
>
> let's use "emit_strings" naming, so it's consistent with emit_zeroes?
Done.
> > @@ -75,6 +75,7 @@ struct btf_dump_data {
>
When this mode is turned on, "emit_zeroes" and "compact" have no effect,
and embedded NUL characters always terminate printing of an array.
Signed-off-by: Blake Jones
---
.../selftests/bpf/prog_tests/btf_dump.c | 106 ++
1 file changed, 106 inserti
On Mon, Jun 2, 2025 at 11:39 AM Alexei Starovoitov
wrote:
> > 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.
Hi Alexei,
Thanks for taking a look at this.
On Sat, May 31, 2025 at 11:20 AM Alexei Starovoitov
wrote:
> Please split selftests vs main libbpf parts.
> [...]
> Please use normal kernel style comments.
> We're gradually getting away from networking style.
> [...]
> we allow up to 100 char per li
['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_stri
11 matches
Mail list logo
