* Re: [PATCH v3 bpf-next 0/4] add btf dumping to bpftool
[not found] <20190425165539.3317350-1-andriin@fb.com>
@ 2019-04-25 19:20 ` Quentin Monnet
2019-04-25 21:53 ` Andrii Nakryiko
[not found] ` <20190425165539.3317350-2-andriin@fb.com>
` (3 subsequent siblings)
4 siblings, 1 reply; 8+ messages in thread
From: Quentin Monnet @ 2019-04-25 19:20 UTC (permalink / raw)
To: Andrii Nakryiko, andrii.nakryiko, kernel-team, netdev, bpf, ast,
daniel, yhs, songliubraving, kafai, acme
2019-04-25 09:55 UTC-0700 ~ Andrii Nakryiko <andriin@fb.com>
> This patch set adds a new `bpftool btf dump` sub-command, which allows to dump
> BTF contents (only types for now). Currently it only outputs low-level
> content, almost 1:1 with binary BTF format, but follow up patches will add
> ability to dump BTF types as a compilable C header file. JSON output is
> supported as well.
>
> Patch #1 adds `btf` sub-command, dumping BTF types in human-readable format.
> It also implements reading .BTF data from ELF file.
> Patch #2 adds minimal documentation with output format examples and different
> ways to specify source of BTF data.
> Patch #3 adds support for btf command in bash-completion/bpftool script.
> Patch #4 fixes minor indentation issue in bash-completion script.
>
> Output format is mostly following existing format of BPF verifier log, but
> deviates from it in few places. More details are in commit message for patch
> #1.
>
> Example of output for all supported BTF kinds are in patch #2 as part of
> documentation. Some field names are quite verbose and I'd rather shorten them,
> if we don't feel like being very close to BPF verifier names is a necessity,
> but in this patch I left them exactly the same as in verifier log.
>
> v2->v3:
> - make map's key|value|kv|all suggestion more precise (Quentin)
> - fix default case indentations (Quentin)
>
> v1->v2:
> - fix unnecessary trailing whitespaces in bpftool-btf.rst (Yonghong)
> - add btf in main.c for a list of possible OBJECTs
> - handle unknown keyword under `bpftool btf dump` (Yonghong)
>
> Andrii Nakryiko (4):
> bpftool: add ability to dump BTF types
> bpftool/docs: add btf sub-command documentation
> bpftool: add bash completions for btf command
> bpftool: fix indendation in bash-completion/bpftool
>
> .../bpf/bpftool/Documentation/bpftool-btf.rst | 205 +++++++
> .../bpftool/Documentation/bpftool-cgroup.rst | 3 +-
> .../bpftool/Documentation/bpftool-feature.rst | 3 +-
> .../bpf/bpftool/Documentation/bpftool-map.rst | 3 +-
> .../bpf/bpftool/Documentation/bpftool-net.rst | 3 +-
> .../bpftool/Documentation/bpftool-perf.rst | 3 +-
> .../bpftool/Documentation/bpftool-prog.rst | 3 +-
> tools/bpf/bpftool/Documentation/bpftool.rst | 3 +-
> tools/bpf/bpftool/bash-completion/bpftool | 68 +-
> tools/bpf/bpftool/btf.c | 580 ++++++++++++++++++
> tools/bpf/bpftool/main.c | 3 +-
> tools/bpf/bpftool/main.h | 1 +
> 12 files changed, 859 insertions(+), 19 deletions(-)
> create mode 100644 tools/bpf/bpftool/Documentation/bpftool-btf.rst
> create mode 100644 tools/bpf/bpftool/btf.c
>
Hi Andrii,
I got all your patches this time, but I think this is because you CC-ed
me (thanks!), I cannot see them in patchwork or in the archives of the
mailing lists (not even the cover letter this time, it seems). I don't
know what can be the cause of it :(.
Other than this, I have a few nitpicks on the first two patches, I'm
sending them separately.
Best regards,
Quentin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 bpf-next 1/4] bpftool: add ability to dump BTF types
[not found] ` <20190425165539.3317350-2-andriin@fb.com>
@ 2019-04-25 19:20 ` Quentin Monnet
2019-04-25 22:00 ` Andrii Nakryiko
0 siblings, 1 reply; 8+ messages in thread
From: Quentin Monnet @ 2019-04-25 19:20 UTC (permalink / raw)
To: Andrii Nakryiko, andrii.nakryiko, kernel-team, netdev, bpf, ast,
daniel, yhs, songliubraving, kafai, acme
Cc: Arnaldo Carvalho de Melo
2019-04-25 09:55 UTC-0700 ~ Andrii Nakryiko <andriin@fb.com>
> Add new `btf dump` sub-command to bpftool. It allows to dump
> human-readable low-level BTF types representation of BTF types. BTF can
> be retrieved from few different sources:
> - from BTF object by ID;
> - from PROG, if it has associated BTF;
> - from MAP, if it has associated BTF data; it's possible to narrow
> down types to either key type, value type, both, or all BTF types;
> - from ELF file (.BTF section).
>
> Output format mostly follows BPF verifier log format with few notable
> exceptions:
> - all the type/field/param/etc names are enclosed in single quotes to
> allow easier grepping and to stand out a little bit more;
> - FUNC_PROTO output follows STRUCT/UNION/ENUM format of having one
> line per each argument; this is more uniform and allows easy
> grepping, as opposed to succinct, but inconvenient format that BPF
> verifier log is using.
>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Alexei Starovoitov <ast@fb.com>
> Cc: Yonghong Song <yhs@fb.com>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Cc: Song Liu <songliubraving@fb.com>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Acked-by: Yonghong Song <yhs@fb.com>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> tools/bpf/bpftool/btf.c | 580 +++++++++++++++++++++++++++++++++++++++
> tools/bpf/bpftool/main.c | 3 +-
> tools/bpf/bpftool/main.h | 1 +
> 3 files changed, 583 insertions(+), 1 deletion(-)
> create mode 100644 tools/bpf/bpftool/btf.c
>
> diff --git a/tools/bpf/bpftool/btf.c b/tools/bpf/bpftool/btf.c
> new file mode 100644
> index 000000000000..cbf04850c798
> --- /dev/null
> +++ b/tools/bpf/bpftool/btf.c
> @@ -0,0 +1,580 @@
> +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +/* Copyright (C) 2019 Facebook */
> +
> +#include <errno.h>
> +#include <fcntl.h>
> +#include <linux/err.h>
> +#include <stdbool.h>
> +#include <stdio.h>
> +#include <string.h>
> +#include <unistd.h>
> +#include <gelf.h>
> +#include <bpf.h>
> +#include <linux/btf.h>
Can we have as in prog.c/map.c: standard includes sorted alphabetically,
then linux/ includes, then bpf includes?
> +
> +#include "btf.h"
> +#include "json_writer.h"
> +#include "main.h"
> +
> +static const char * const btf_kind_str[NR_BTF_KINDS] = {
> + [BTF_KIND_UNKN] = "UNKNOWN",
> + [BTF_KIND_INT] = "INT",
> + [BTF_KIND_PTR] = "PTR",
> + [BTF_KIND_ARRAY] = "ARRAY",
> + [BTF_KIND_STRUCT] = "STRUCT",
> + [BTF_KIND_UNION] = "UNION",
> + [BTF_KIND_ENUM] = "ENUM",
> + [BTF_KIND_FWD] = "FWD",
> + [BTF_KIND_TYPEDEF] = "TYPEDEF",
> + [BTF_KIND_VOLATILE] = "VOLATILE",
> + [BTF_KIND_CONST] = "CONST",
> + [BTF_KIND_RESTRICT] = "RESTRICT",
> + [BTF_KIND_FUNC] = "FUNC",
> + [BTF_KIND_FUNC_PROTO] = "FUNC_PROTO",
> + [BTF_KIND_VAR] = "VAR",
> + [BTF_KIND_DATASEC] = "DATASEC",
> +};
> +
> +static const char *btf_int_enc_str(__u8 encoding)
> +{
> + switch (encoding) {
> + case 0:
> + return "(none)";
> + case BTF_INT_SIGNED:
> + return "SIGNED";
> + case BTF_INT_CHAR:
> + return "CHAR";
> + case BTF_INT_BOOL:
> + return "BOOL";
> + default:
> + return "UNKN";
> + }
> +}
> +
> +static const char *btf_var_linkage_str(__u32 linkage)
> +{
> + switch (linkage) {
> + case BTF_VAR_STATIC:
> + return "static";
> + case BTF_VAR_GLOBAL_ALLOCATED:
> + return "global-alloc";
> + default:
> + return "(unknown)";
> + }
> +}
> +
> +static const char *btf_str(const struct btf *btf, __u32 off)
> +{
> + if (!off)
> + return "(anon)";
> + return btf__name_by_offset(btf, off) ? : "(invalid)";
> +}
> +
> +static int dump_btf_type(const struct btf *btf, __u32 id,
> + const struct btf_type *t)
> +{
> + int kind = BTF_INFO_KIND(t->info);
> + int safe_kind = kind <= BTF_KIND_MAX ? kind : BTF_KIND_UNKN;
> + json_writer_t *w = json_wtr;
Can we keep reverse-Christmas tree style for declarations? Assigning the
values can be done on its own after the declarations.
> +
> + if (json_output) {
> + jsonw_start_object(w);
> + jsonw_uint_field(w, "id", id);
> + jsonw_string_field(w, "kind", btf_kind_str[safe_kind]);
> + jsonw_string_field(w, "name", btf_str(btf, t->name_off));
> + } else {
> + printf("[%u] %s '%s'", id, btf_kind_str[safe_kind],
> + btf_str(btf, t->name_off));
> + }
> +
> + switch (BTF_INFO_KIND(t->info)) {
> + case BTF_KIND_INT: {
> + __u32 v = *(__u32 *)(t + 1);
> + const char *enc = btf_int_enc_str(BTF_INT_ENCODING(v));
Same thing here.
> +
> + if (json_output) {
> + jsonw_uint_field(w, "size", t->size);
> + jsonw_uint_field(w, "bits_offset", BTF_INT_OFFSET(v));
> + jsonw_uint_field(w, "nr_bits", BTF_INT_BITS(v));
> + jsonw_string_field(w, "encoding", enc);
> + } else {
> + printf(" size=%u bits_offset=%u nr_bits=%u encoding=%s",
> + t->size, BTF_INT_OFFSET(v), BTF_INT_BITS(v),
> + enc);
> + }
> + break;
> + }
> + case BTF_KIND_PTR:
[...]
printf(" type_id=%u", t->type);
> + break;
> + case BTF_KIND_FUNC_PROTO: {
> + const struct btf_param *p = (const void *)(t + 1);
> + __u16 vlen = BTF_INFO_VLEN(t->info);
> + int i;
> +
> + if (json_output) {
> + jsonw_uint_field(w, "ret_type_id", t->type);
> + jsonw_uint_field(w, "vlen", vlen);
> + jsonw_name(w, "params");
> + jsonw_start_array(w);
> + } else {
> + printf(" ret_type_id=%u vlen=%u", t->type, vlen);
> + }
> + for (i = 0; i < vlen; i++, p++) {
> + const char *name = btf_str(btf, p->name_off);
> +
> + if (json_output) {
> + jsonw_start_object(w);
> + jsonw_string_field(w, "name", name);
> + jsonw_uint_field(w, "type_id", p->type);
> + jsonw_end_object(w);
> + } else {
> + printf("\n\t'%s' type_id=%u", name, p->type);
> + }
> + }
> + if (json_output)
> + jsonw_end_array(w);
> + break;
> + }
> + case BTF_KIND_VAR: {
> + const struct btf_var *v = (const void *)(t + 1);
> + const char *linkage = btf_var_linkage_str(v->linkage);
And here please.
> +
> + if (json_output) {
> + jsonw_uint_field(w, "type_id", t->type);
> + jsonw_string_field(w, "linkage", linkage);
> + } else {
> + printf(" type_id=%u, linkage=%s", t->type, linkage);
> + }
> + break;
> + }
> + case BTF_KIND_DATASEC: {
[...]
> +static int do_help(int argc, char **argv)
> +{
> + if (json_output) {
> + jsonw_null(json_wtr);
> + return 0;
> + }
> +
> + fprintf(stderr,
> + "Usage: %s btf dump BTF_SRC\n"
Why so much space between "dump" and "BTF_SRC"?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 bpf-next 2/4] bpftool/docs: add btf sub-command documentation
[not found] ` <20190425165539.3317350-3-andriin@fb.com>
@ 2019-04-25 19:20 ` Quentin Monnet
2019-04-25 22:24 ` Andrii Nakryiko
0 siblings, 1 reply; 8+ messages in thread
From: Quentin Monnet @ 2019-04-25 19:20 UTC (permalink / raw)
To: Andrii Nakryiko, andrii.nakryiko, kernel-team, netdev, bpf, ast,
daniel, yhs, songliubraving, kafai, acme
Cc: Arnaldo Carvalho de Melo
2019-04-25 09:55 UTC-0700 ~ Andrii Nakryiko <andriin@fb.com>
> Document usage and sample output format for `btf dump` sub-command.
>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Alexei Starovoitov <ast@fb.com>
> Cc: Yonghong Song <yhs@fb.com>
> Cc: Martin KaFai Lau <kafai@fb.com>
> Cc: Song Liu <songliubraving@fb.com>
> Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> Acked-by: Yonghong Song <yhs@fb.com>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> .../bpf/bpftool/Documentation/bpftool-btf.rst | 205 ++++++++++++++++++
> .../bpftool/Documentation/bpftool-cgroup.rst | 3 +-
> .../bpftool/Documentation/bpftool-feature.rst | 3 +-
> .../bpf/bpftool/Documentation/bpftool-map.rst | 3 +-
> .../bpf/bpftool/Documentation/bpftool-net.rst | 3 +-
> .../bpftool/Documentation/bpftool-perf.rst | 3 +-
> .../bpftool/Documentation/bpftool-prog.rst | 3 +-
> tools/bpf/bpftool/Documentation/bpftool.rst | 3 +-
> 8 files changed, 219 insertions(+), 7 deletions(-)
> create mode 100644 tools/bpf/bpftool/Documentation/bpftool-btf.rst
>
> diff --git a/tools/bpf/bpftool/Documentation/bpftool-btf.rst b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> new file mode 100644
> index 000000000000..d37d782a1cfb
> --- /dev/null
> +++ b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> @@ -0,0 +1,205 @@
> +================
> +bpftool-btf
> +================
> +-------------------------------------------------------------------------------
> +tool for inspection of BTF data
> +-------------------------------------------------------------------------------
> +
> +:Manual section: 8
> +
> +SYNOPSIS
> +========
> +
> + **bpftool** [*OPTIONS*] **btf** *COMMAND*
> +
> + *OPTIONS* := { { **-j** | **--json** } [{ **-p** | **--pretty** }] }
> +
> + *COMMANDS* :=
> + { **dump** | **help** }
Commands fit on a single line.
> +
> +MAP COMMANDS
> +=============
> +
> +| **bpftool** **btf dump** *BTF_SRC*
Why so much space between "dump" and "BTF_SRC"? Is it to make it easier
to align it if other commands are added in the future? For now it looks
a bit strange in my opinion.
> +| **bpftool** **btf help**
> +|
> +| *BTF_SRC* := { **id** *BTF_ID* | **prog** *PROG* | **map** *MAP* [{**key** | **value** | **kv** | **all**}] | **file** *FILE* }
> +| *MAP* := { **id** *MAP_ID* | **pinned** *FILE* }
> +| *PROG* := { **id** *PROG_ID* | **pinned** *FILE* | **tag** *PROG_TAG* }
> +
> +DESCRIPTION
> +===========
> + **bpftool map dump** *MAP*
That's a lot of space again. I think you copied it from bpftool-map.rst.
But it looks like you forgot to replace "map dump MAP" with "btf dump
BTF_SRC" :).
A brief description of key/value/kv/all, or of what kind of FILE is
expected, would be welcome here.
> + Dump BTF entries from a given *BTF_SRC*.
> +
> + **bpftool map help**
"bpftool btf help"
> + Print short help message.
> +
> +OPTIONS
> +=======
> + -h, --help
> + Print short generic help message (similar to **bpftool help**).
> +
> + -V, --version
> + Print version number (similar to **bpftool version**).
> +
> + -j, --json
> + Generate JSON output. For commands that cannot produce JSON, this
> + option has no effect.
> +
> + -p, --pretty
> + Generate human-readable JSON output. Implies **-j**.
> +
> +EXAMPLES
> +========
> +**# bpftool btf dump id 1226**
> +::
> +
> + [1] PTR '(anon)' type_id=2
> + [2] STRUCT 'dummy_tracepoint_args' size=16 vlen=2
> + 'pad' type_id=3 bits_offset=0
> + 'sock' type_id=4 bits_offset=64
> + [3] INT 'long long unsigned int' size=8 bits_offset=0 nr_bits=64 encoding=(none)
> + [4] PTR '(anon)' type_id=5
> + [5] FWD 'sock' fwd_kind=union
> +
> +This gives an example of default output for all supported BTF kinds.
> +
> +**$ cat prog.c**
> +::
> +
> + struct fwd_struct;
> +
> + enum my_enum {
> + VAL1 = 3,
> + VAL2 = 7,
> + };
> +
> + typedef struct my_struct my_struct_t;
> +
> + struct my_struct {
> + const unsigned int const_int_field;
> + int bitfield_field: 4;
> + char arr_field[16];
> + const struct fwd_struct *restrict fwd_field;
> + enum my_enum enum_field;
> + volatile my_struct_t *typedef_ptr_field;
> + };
> +
> + union my_union {
> + int a;
> + struct my_struct b;
> + };
> +
> + struct my_struct struct_global_var __attribute__((section("data_sec"))) = {
> + .bitfield_field = 3,
> + .enum_field = VAL1,
> + };
> + int global_var __attribute__((section("data_sec"))) = 7;
> +
> + __attribute__((noinline))
> + int my_func(union my_union *arg1, int arg2)
> + {
> + static int static_var __attribute__((section("data_sec"))) = 123;
> + static_var++;
> + return static_var;
> + }
> +
> +**$ bpftool btf dump file prog.o**
> +::
> +
> + [1] PTR '(anon)' type_id=2
> + [2] UNION 'my_union' size=48 vlen=2
> + 'a' type_id=3 bits_offset=0
> + 'b' type_id=4 bits_offset=0
> + [3] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
> + [4] STRUCT 'my_struct' size=48 vlen=6
> + 'const_int_field' type_id=5 bits_offset=0
> + 'bitfield_field' type_id=3 bits_offset=32 bitfield_size=4
> + 'arr_field' type_id=8 bits_offset=40
> + 'fwd_field' type_id=10 bits_offset=192
> + 'enum_field' type_id=14 bits_offset=256
> + 'typedef_ptr_field' type_id=15 bits_offset=320
> + [5] CONST '(anon)' type_id=6
> + [6] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none)
> + [7] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
> + [8] ARRAY '(anon)' type_id=7 index_type_id=9 nr_elems=16
> + [9] INT '__ARRAY_SIZE_TYPE__' size=4 bits_offset=0 nr_bits=32 encoding=(none)
> + [10] RESTRICT '(anon)' type_id=11
> + [11] PTR '(anon)' type_id=12
> + [12] CONST '(anon)' type_id=13
> + [13] FWD 'fwd_struct' fwd_kind=union
> + [14] ENUM 'my_enum' size=4 vlen=2
> + 'VAL1' val=3
> + 'VAL2' val=7
> + [15] PTR '(anon)' type_id=16
> + [16] VOLATILE '(anon)' type_id=17
> + [17] TYPEDEF 'my_struct_t' type_id=4
> + [18] FUNC_PROTO '(anon)' ret_type_id=3 vlen=2
> + 'arg1' type_id=1
> + 'arg2' type_id=3
> + [19] FUNC 'my_func' type_id=18
> + [20] VAR 'struct_global_var' type_id=4, linkage=global-alloc
> + [21] VAR 'global_var' type_id=3, linkage=global-alloc
> + [22] VAR 'my_func.static_var' type_id=3, linkage=static
> + [23] DATASEC 'data_sec' size=0 vlen=3
> + type_id=20 offset=0 size=48
> + type_id=21 offset=0 size=4
> + type_id=22 offset=52 size=4
> +
> +The following commands print BTF types associated with specified map's key,
> +value, both key and value, and all BTF types, respectively. By default, both
> +key and value types will be printed.
This kind of info should go into the command's description (although I
don't mind if we also repeat it here).
> +
> +**# bpftool btf dump map id 123 key**
> +
> +::
> +
> + [39] TYPEDEF 'u32' type_id=37
> +
> +**# bpftool btf dump map id 123 value**
> +
> +::
> +
> + [86] PTR '(anon)' type_id=87
> +
> +**# bpftool btf dump map id 123 kv**
> +
> +::
> +
> + [39] TYPEDEF 'u32' type_id=37
> + [86] PTR '(anon)' type_id=87
> +
> +**# bpftool btf dump map id 123 all**
> +
> +::
> +
> + [1] PTR '(anon)' type_id=0
> + .
> + .
> + .
> + [2866] ARRAY '(anon)' type_id=52 index_type_id=51 nr_elems=4
> +
> +All the standard ways to specify map or program is supported:
s/is/are/
> +
> +**# bpftool btf dump map id 123**
> +
> +**# bpftool btf dump map pinned /sys/fs/bpf/map_name**
> +
> +**# bpftool btf dump prog id 456**
> +
> +**# bpftool btf dump prog tag b88e0a09b1d9759d**
> +
> +**# bpftool btf dump prog pinned /sys/fs/bpf/prog_name**
> +
> +SEE ALSO
> +========
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 bpf-next 3/4] bpftool: add bash completions for btf command
[not found] ` <20190425165539.3317350-4-andriin@fb.com>
@ 2019-04-25 19:21 ` Quentin Monnet
0 siblings, 0 replies; 8+ messages in thread
From: Quentin Monnet @ 2019-04-25 19:21 UTC (permalink / raw)
To: Andrii Nakryiko, andrii.nakryiko, kernel-team, netdev, bpf, ast,
daniel, yhs, songliubraving, kafai, acme
2019-04-25 09:55 UTC-0700 ~ Andrii Nakryiko <andriin@fb.com>
> Add full support for btf command in bash-completion script.
>
> Cc: Quentin Monnet <quentin.monnet@netronome.com>
> Cc: Yonghong Song <yhs@fb.com>
> Cc: Alexei Starovoitov <ast@fb.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> tools/bpf/bpftool/bash-completion/bpftool | 46 +++++++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
> index 9f3ffe1e26ab..bca91d04ed35 100644
> --- a/tools/bpf/bpftool/bash-completion/bpftool
> +++ b/tools/bpf/bpftool/bash-completion/bpftool
> @@ -217,6 +217,7 @@ _bpftool()
> done
> cur=${words[cword]}
> prev=${words[cword - 1]}
> + pprev=${words[cword - 2]}
>
> local object=${words[1]} command=${words[2]}
>
> @@ -607,6 +608,51 @@ _bpftool()
> ;;
> esac
> ;;
> + btf)
> + local PROG_TYPE='id pinned tag'
> + local MAP_TYPE='id pinned'
> + case $command in
> + dump)
> + case $prev in
> + $command)
> + COMPREPLY+=( $( compgen -W "id map prog file" -- \
> + "$cur" ) )
> + return 0
> + ;;
> + prog)
> + COMPREPLY=( $( compgen -W "$PROG_TYPE" -- "$cur" ) )
> + return 0
> + ;;
> + map)
> + COMPREPLY=( $( compgen -W "$MAP_TYPE" -- "$cur" ) )
> + return 0
> + ;;
> + id)
> + case $pprev in
> + prog)
> + _bpftool_get_prog_ids
> + ;;
> + map)
> + _bpftool_get_map_ids
> + ;;
> + esac
> + return 0
> + ;;
> + *)
> + if [[ $cword == 6 ]] && [[ ${words[3]} == "map" ]]; then
> + COMPREPLY+=( $( compgen -W 'key value kv all' -- \
> + "$cur" ) )
> + fi
> + return 0
> + ;;
> + esac
> + ;;
> + *)
> + [[ $prev == $object ]] && \
> + COMPREPLY=( $( compgen -W 'dump help' -- "$cur" ) )
> + ;;
> + esac
> + ;;
> cgroup)
> case $command in
> show|list)
>
I haven't tried with the latest change, but the code looks good to me.
Thanks!
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 bpf-next 4/4] bpftool: fix indendation in bash-completion/bpftool
[not found] ` <20190425165539.3317350-5-andriin@fb.com>
@ 2019-04-25 19:21 ` Quentin Monnet
0 siblings, 0 replies; 8+ messages in thread
From: Quentin Monnet @ 2019-04-25 19:21 UTC (permalink / raw)
To: Andrii Nakryiko, andrii.nakryiko, kernel-team, netdev, bpf, ast,
daniel, yhs, songliubraving, kafai, acme
2019-04-25 09:55 UTC-0700 ~ Andrii Nakryiko <andriin@fb.com>
> Fix misaligned default case branch for `prog dump` sub-command.
>
> Reported-by: Quentin Monnet <quentin.monnet@netronome.com>
> Cc: Yonghong Song <yhs@fb.com>
> Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> ---
> tools/bpf/bpftool/bash-completion/bpftool | 22 +++++++++++-----------
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/tools/bpf/bpftool/bash-completion/bpftool b/tools/bpf/bpftool/bash-completion/bpftool
> index bca91d04ed35..50e402a5a9c8 100644
> --- a/tools/bpf/bpftool/bash-completion/bpftool
> +++ b/tools/bpf/bpftool/bash-completion/bpftool
> @@ -273,17 +273,17 @@ _bpftool()
> "$cur" ) )
> return 0
> ;;
> - *)
> - _bpftool_once_attr 'file'
> - if _bpftool_search_list 'xlated'; then
> - COMPREPLY+=( $( compgen -W 'opcodes visual linum' -- \
> - "$cur" ) )
> - else
> - COMPREPLY+=( $( compgen -W 'opcodes linum' -- \
> - "$cur" ) )
> - fi
> - return 0
> - ;;
> + *)
> + _bpftool_once_attr 'file'
> + if _bpftool_search_list 'xlated'; then
> + COMPREPLY+=( $( compgen -W 'opcodes visual linum' -- \
> + "$cur" ) )
> + else
> + COMPREPLY+=( $( compgen -W 'opcodes linum' -- \
> + "$cur" ) )
> + fi
> + return 0
> + ;;
> esac
> ;;
> pin)
>
Thanks for that!
Reviewed-by: Quentin Monnet <quentin.monnet@netronome.com>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 bpf-next 0/4] add btf dumping to bpftool
2019-04-25 19:20 ` [PATCH v3 bpf-next 0/4] add btf dumping to bpftool Quentin Monnet
@ 2019-04-25 21:53 ` Andrii Nakryiko
0 siblings, 0 replies; 8+ messages in thread
From: Andrii Nakryiko @ 2019-04-25 21:53 UTC (permalink / raw)
To: Quentin Monnet
Cc: Andrii Nakryiko, Kernel Team, Networking, bpf,
Alexei Starovoitov, Daniel Borkmann, Yonghong Song, Song Liu,
Martin Lau, Arnaldo Carvalho de Melo
On Thu, Apr 25, 2019 at 12:20 PM Quentin Monnet
<quentin.monnet@netronome.com> wrote:
>
> 2019-04-25 09:55 UTC-0700 ~ Andrii Nakryiko <andriin@fb.com>
> > This patch set adds a new `bpftool btf dump` sub-command, which allows to dump
> > BTF contents (only types for now). Currently it only outputs low-level
> > content, almost 1:1 with binary BTF format, but follow up patches will add
> > ability to dump BTF types as a compilable C header file. JSON output is
> > supported as well.
> >
> > Patch #1 adds `btf` sub-command, dumping BTF types in human-readable format.
> > It also implements reading .BTF data from ELF file.
> > Patch #2 adds minimal documentation with output format examples and different
> > ways to specify source of BTF data.
> > Patch #3 adds support for btf command in bash-completion/bpftool script.
> > Patch #4 fixes minor indentation issue in bash-completion script.
> >
> > Output format is mostly following existing format of BPF verifier log, but
> > deviates from it in few places. More details are in commit message for patch
> > #1.
> >
> > Example of output for all supported BTF kinds are in patch #2 as part of
> > documentation. Some field names are quite verbose and I'd rather shorten them,
> > if we don't feel like being very close to BPF verifier names is a necessity,
> > but in this patch I left them exactly the same as in verifier log.
> >
> > v2->v3:
> > - make map's key|value|kv|all suggestion more precise (Quentin)
> > - fix default case indentations (Quentin)
> >
> > v1->v2:
> > - fix unnecessary trailing whitespaces in bpftool-btf.rst (Yonghong)
> > - add btf in main.c for a list of possible OBJECTs
> > - handle unknown keyword under `bpftool btf dump` (Yonghong)
> >
> > Andrii Nakryiko (4):
> > bpftool: add ability to dump BTF types
> > bpftool/docs: add btf sub-command documentation
> > bpftool: add bash completions for btf command
> > bpftool: fix indendation in bash-completion/bpftool
> >
> > .../bpf/bpftool/Documentation/bpftool-btf.rst | 205 +++++++
> > .../bpftool/Documentation/bpftool-cgroup.rst | 3 +-
> > .../bpftool/Documentation/bpftool-feature.rst | 3 +-
> > .../bpf/bpftool/Documentation/bpftool-map.rst | 3 +-
> > .../bpf/bpftool/Documentation/bpftool-net.rst | 3 +-
> > .../bpftool/Documentation/bpftool-perf.rst | 3 +-
> > .../bpftool/Documentation/bpftool-prog.rst | 3 +-
> > tools/bpf/bpftool/Documentation/bpftool.rst | 3 +-
> > tools/bpf/bpftool/bash-completion/bpftool | 68 +-
> > tools/bpf/bpftool/btf.c | 580 ++++++++++++++++++
> > tools/bpf/bpftool/main.c | 3 +-
> > tools/bpf/bpftool/main.h | 1 +
> > 12 files changed, 859 insertions(+), 19 deletions(-)
> > create mode 100644 tools/bpf/bpftool/Documentation/bpftool-btf.rst
> > create mode 100644 tools/bpf/bpftool/btf.c
> >
>
> Hi Andrii,
>
> I got all your patches this time, but I think this is because you CC-ed
> me (thanks!), I cannot see them in patchwork or in the archives of the
> mailing lists (not even the cover letter this time, it seems). I don't
> know what can be the cause of it :(.
Yeah, it's strange. I'll try to shorten CC list and see if that helps.
I must be in some list of spammer or something. :)
>
> Other than this, I have a few nitpicks on the first two patches, I'm
> sending them separately.
Thanks!
>
> Best regards,
> Quentin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 bpf-next 1/4] bpftool: add ability to dump BTF types
2019-04-25 19:20 ` [PATCH v3 bpf-next 1/4] bpftool: add ability to dump BTF types Quentin Monnet
@ 2019-04-25 22:00 ` Andrii Nakryiko
0 siblings, 0 replies; 8+ messages in thread
From: Andrii Nakryiko @ 2019-04-25 22:00 UTC (permalink / raw)
To: Quentin Monnet
Cc: Andrii Nakryiko, Kernel Team, Networking, bpf,
Alexei Starovoitov, Daniel Borkmann, Yonghong Song, Song Liu,
Martin Lau, Arnaldo Carvalho de Melo, Arnaldo Carvalho de Melo
On Thu, Apr 25, 2019 at 12:20 PM Quentin Monnet
<quentin.monnet@netronome.com> wrote:
>
> 2019-04-25 09:55 UTC-0700 ~ Andrii Nakryiko <andriin@fb.com>
> > Add new `btf dump` sub-command to bpftool. It allows to dump
> > human-readable low-level BTF types representation of BTF types. BTF can
> > be retrieved from few different sources:
> > - from BTF object by ID;
> > - from PROG, if it has associated BTF;
> > - from MAP, if it has associated BTF data; it's possible to narrow
> > down types to either key type, value type, both, or all BTF types;
> > - from ELF file (.BTF section).
> >
> > Output format mostly follows BPF verifier log format with few notable
> > exceptions:
> > - all the type/field/param/etc names are enclosed in single quotes to
> > allow easier grepping and to stand out a little bit more;
> > - FUNC_PROTO output follows STRUCT/UNION/ENUM format of having one
> > line per each argument; this is more uniform and allows easy
> > grepping, as opposed to succinct, but inconvenient format that BPF
> > verifier log is using.
> >
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > Cc: Alexei Starovoitov <ast@fb.com>
> > Cc: Yonghong Song <yhs@fb.com>
> > Cc: Martin KaFai Lau <kafai@fb.com>
> > Cc: Song Liu <songliubraving@fb.com>
> > Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> > Acked-by: Yonghong Song <yhs@fb.com>
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > tools/bpf/bpftool/btf.c | 580 +++++++++++++++++++++++++++++++++++++++
> > tools/bpf/bpftool/main.c | 3 +-
> > tools/bpf/bpftool/main.h | 1 +
> > 3 files changed, 583 insertions(+), 1 deletion(-)
> > create mode 100644 tools/bpf/bpftool/btf.c
> >
> > diff --git a/tools/bpf/bpftool/btf.c b/tools/bpf/bpftool/btf.c
> > new file mode 100644
> > index 000000000000..cbf04850c798
> > --- /dev/null
> > +++ b/tools/bpf/bpftool/btf.c
> > @@ -0,0 +1,580 @@
> > +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +/* Copyright (C) 2019 Facebook */
> > +
> > +#include <errno.h>
> > +#include <fcntl.h>
> > +#include <linux/err.h>
> > +#include <stdbool.h>
> > +#include <stdio.h>
> > +#include <string.h>
> > +#include <unistd.h>
> > +#include <gelf.h>
> > +#include <bpf.h>
> > +#include <linux/btf.h>
>
> Can we have as in prog.c/map.c: standard includes sorted alphabetically,
> then linux/ includes, then bpf includes?
Sure, will do.
>
> > +
> > +#include "btf.h"
> > +#include "json_writer.h"
> > +#include "main.h"
> > +
> > +static const char * const btf_kind_str[NR_BTF_KINDS] = {
> > + [BTF_KIND_UNKN] = "UNKNOWN",
> > + [BTF_KIND_INT] = "INT",
> > + [BTF_KIND_PTR] = "PTR",
> > + [BTF_KIND_ARRAY] = "ARRAY",
> > + [BTF_KIND_STRUCT] = "STRUCT",
> > + [BTF_KIND_UNION] = "UNION",
> > + [BTF_KIND_ENUM] = "ENUM",
> > + [BTF_KIND_FWD] = "FWD",
> > + [BTF_KIND_TYPEDEF] = "TYPEDEF",
> > + [BTF_KIND_VOLATILE] = "VOLATILE",
> > + [BTF_KIND_CONST] = "CONST",
> > + [BTF_KIND_RESTRICT] = "RESTRICT",
> > + [BTF_KIND_FUNC] = "FUNC",
> > + [BTF_KIND_FUNC_PROTO] = "FUNC_PROTO",
> > + [BTF_KIND_VAR] = "VAR",
> > + [BTF_KIND_DATASEC] = "DATASEC",
> > +};
> > +
> > +static const char *btf_int_enc_str(__u8 encoding)
> > +{
> > + switch (encoding) {
> > + case 0:
> > + return "(none)";
> > + case BTF_INT_SIGNED:
> > + return "SIGNED";
> > + case BTF_INT_CHAR:
> > + return "CHAR";
> > + case BTF_INT_BOOL:
> > + return "BOOL";
> > + default:
> > + return "UNKN";
> > + }
> > +}
> > +
> > +static const char *btf_var_linkage_str(__u32 linkage)
> > +{
> > + switch (linkage) {
> > + case BTF_VAR_STATIC:
> > + return "static";
> > + case BTF_VAR_GLOBAL_ALLOCATED:
> > + return "global-alloc";
> > + default:
> > + return "(unknown)";
> > + }
> > +}
> > +
> > +static const char *btf_str(const struct btf *btf, __u32 off)
> > +{
> > + if (!off)
> > + return "(anon)";
> > + return btf__name_by_offset(btf, off) ? : "(invalid)";
> > +}
> > +
> > +static int dump_btf_type(const struct btf *btf, __u32 id,
> > + const struct btf_type *t)
> > +{
> > + int kind = BTF_INFO_KIND(t->info);
> > + int safe_kind = kind <= BTF_KIND_MAX ? kind : BTF_KIND_UNKN;
> > + json_writer_t *w = json_wtr;
>
> Can we keep reverse-Christmas tree style for declarations? Assigning the
> values can be done on its own after the declarations.
Ok.
>
> > +
> > + if (json_output) {
> > + jsonw_start_object(w);
> > + jsonw_uint_field(w, "id", id);
> > + jsonw_string_field(w, "kind", btf_kind_str[safe_kind]);
> > + jsonw_string_field(w, "name", btf_str(btf, t->name_off));
> > + } else {
> > + printf("[%u] %s '%s'", id, btf_kind_str[safe_kind],
> > + btf_str(btf, t->name_off));
> > + }
> > +
> > + switch (BTF_INFO_KIND(t->info)) {
> > + case BTF_KIND_INT: {
> > + __u32 v = *(__u32 *)(t + 1);
> > + const char *enc = btf_int_enc_str(BTF_INT_ENCODING(v));
>
> Same thing here.
Fixing.
>
> > +
> > + if (json_output) {
> > + jsonw_uint_field(w, "size", t->size);
> > + jsonw_uint_field(w, "bits_offset", BTF_INT_OFFSET(v));
> > + jsonw_uint_field(w, "nr_bits", BTF_INT_BITS(v));
> > + jsonw_string_field(w, "encoding", enc);
> > + } else {
> > + printf(" size=%u bits_offset=%u nr_bits=%u encoding=%s",
> > + t->size, BTF_INT_OFFSET(v), BTF_INT_BITS(v),
> > + enc);
> > + }
> > + break;
> > + }
> > + case BTF_KIND_PTR:
>
> [...]
>
> printf(" type_id=%u", t->type);
> > + break;
> > + case BTF_KIND_FUNC_PROTO: {
> > + const struct btf_param *p = (const void *)(t + 1);
> > + __u16 vlen = BTF_INFO_VLEN(t->info);
> > + int i;
> > +
> > + if (json_output) {
> > + jsonw_uint_field(w, "ret_type_id", t->type);
> > + jsonw_uint_field(w, "vlen", vlen);
> > + jsonw_name(w, "params");
> > + jsonw_start_array(w);
> > + } else {
> > + printf(" ret_type_id=%u vlen=%u", t->type, vlen);
> > + }
> > + for (i = 0; i < vlen; i++, p++) {
> > + const char *name = btf_str(btf, p->name_off);
> > +
> > + if (json_output) {
> > + jsonw_start_object(w);
> > + jsonw_string_field(w, "name", name);
> > + jsonw_uint_field(w, "type_id", p->type);
> > + jsonw_end_object(w);
> > + } else {
> > + printf("\n\t'%s' type_id=%u", name, p->type);
> > + }
> > + }
> > + if (json_output)
> > + jsonw_end_array(w);
> > + break;
> > + }
> > + case BTF_KIND_VAR: {
> > + const struct btf_var *v = (const void *)(t + 1);
> > + const char *linkage = btf_var_linkage_str(v->linkage);
>
> And here please.
>
> > +
> > + if (json_output) {
> > + jsonw_uint_field(w, "type_id", t->type);
> > + jsonw_string_field(w, "linkage", linkage);
> > + } else {
> > + printf(" type_id=%u, linkage=%s", t->type, linkage);
> > + }
> > + break;
> > + }
> > + case BTF_KIND_DATASEC: {
>
> [...]
>
> > +static int do_help(int argc, char **argv)
> > +{
> > + if (json_output) {
> > + jsonw_null(json_wtr);
> > + return 0;
> > + }
> > +
> > + fprintf(stderr,
> > + "Usage: %s btf dump BTF_SRC\n"
>
> Why so much space between "dump" and "BTF_SRC"?
Followed map.c's style, which has that much space (though in that case
it's aligned on longest command). But seems like prog.c doesn't follow
that. I'll make spacing tighter.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3 bpf-next 2/4] bpftool/docs: add btf sub-command documentation
2019-04-25 19:20 ` [PATCH v3 bpf-next 2/4] bpftool/docs: add btf sub-command documentation Quentin Monnet
@ 2019-04-25 22:24 ` Andrii Nakryiko
0 siblings, 0 replies; 8+ messages in thread
From: Andrii Nakryiko @ 2019-04-25 22:24 UTC (permalink / raw)
To: Quentin Monnet
Cc: Andrii Nakryiko, Kernel Team, Networking, bpf,
Alexei Starovoitov, Daniel Borkmann, Yonghong Song, Song Liu,
Martin Lau, Arnaldo Carvalho de Melo, Arnaldo Carvalho de Melo
On Thu, Apr 25, 2019 at 12:20 PM Quentin Monnet
<quentin.monnet@netronome.com> wrote:
>
> 2019-04-25 09:55 UTC-0700 ~ Andrii Nakryiko <andriin@fb.com>
> > Document usage and sample output format for `btf dump` sub-command.
> >
> > Cc: Daniel Borkmann <daniel@iogearbox.net>
> > Cc: Alexei Starovoitov <ast@fb.com>
> > Cc: Yonghong Song <yhs@fb.com>
> > Cc: Martin KaFai Lau <kafai@fb.com>
> > Cc: Song Liu <songliubraving@fb.com>
> > Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> > Acked-by: Yonghong Song <yhs@fb.com>
> > Signed-off-by: Andrii Nakryiko <andriin@fb.com>
> > ---
> > .../bpf/bpftool/Documentation/bpftool-btf.rst | 205 ++++++++++++++++++
> > .../bpftool/Documentation/bpftool-cgroup.rst | 3 +-
> > .../bpftool/Documentation/bpftool-feature.rst | 3 +-
> > .../bpf/bpftool/Documentation/bpftool-map.rst | 3 +-
> > .../bpf/bpftool/Documentation/bpftool-net.rst | 3 +-
> > .../bpftool/Documentation/bpftool-perf.rst | 3 +-
> > .../bpftool/Documentation/bpftool-prog.rst | 3 +-
> > tools/bpf/bpftool/Documentation/bpftool.rst | 3 +-
> > 8 files changed, 219 insertions(+), 7 deletions(-)
> > create mode 100644 tools/bpf/bpftool/Documentation/bpftool-btf.rst
> >
> > diff --git a/tools/bpf/bpftool/Documentation/bpftool-btf.rst b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> > new file mode 100644
> > index 000000000000..d37d782a1cfb
> > --- /dev/null
> > +++ b/tools/bpf/bpftool/Documentation/bpftool-btf.rst
> > @@ -0,0 +1,205 @@
> > +================
> > +bpftool-btf
> > +================
> > +-------------------------------------------------------------------------------
> > +tool for inspection of BTF data
> > +-------------------------------------------------------------------------------
> > +
> > +:Manual section: 8
> > +
> > +SYNOPSIS
> > +========
> > +
> > + **bpftool** [*OPTIONS*] **btf** *COMMAND*
> > +
> > + *OPTIONS* := { { **-j** | **--json** } [{ **-p** | **--pretty** }] }
> > +
> > + *COMMANDS* :=
> > + { **dump** | **help** }
>
> Commands fit on a single line.
Fixed.
>
> > +
> > +MAP COMMANDS
> > +=============
> > +
> > +| **bpftool** **btf dump** *BTF_SRC*
>
> Why so much space between "dump" and "BTF_SRC"? Is it to make it easier
> to align it if other commands are added in the future? For now it looks
> a bit strange in my opinion.
I took bpftool-map.rst as a source and kept existing spacing. Will fix.
>
> > +| **bpftool** **btf help**
> > +|
> > +| *BTF_SRC* := { **id** *BTF_ID* | **prog** *PROG* | **map** *MAP* [{**key** | **value** | **kv** | **all**}] | **file** *FILE* }
> > +| *MAP* := { **id** *MAP_ID* | **pinned** *FILE* }
> > +| *PROG* := { **id** *PROG_ID* | **pinned** *FILE* | **tag** *PROG_TAG* }
> > +
> > +DESCRIPTION
> > +===========
> > + **bpftool map dump** *MAP*
>
> That's a lot of space again. I think you copied it from bpftool-map.rst.
> But it looks like you forgot to replace "map dump MAP" with "btf dump
> BTF_SRC" :).
Yeah, and few more places as well. I think I fixed all of those now.
>
> A brief description of key/value/kv/all, or of what kind of FILE is
> expected, would be welcome here.
Added.
>
> > + Dump BTF entries from a given *BTF_SRC*.
> > +
> > + **bpftool map help**
>
> "bpftool btf help"
>
> > + Print short help message.
> > +
> > +OPTIONS
> > +=======
> > + -h, --help
> > + Print short generic help message (similar to **bpftool help**).
> > +
> > + -V, --version
> > + Print version number (similar to **bpftool version**).
> > +
> > + -j, --json
> > + Generate JSON output. For commands that cannot produce JSON, this
> > + option has no effect.
> > +
> > + -p, --pretty
> > + Generate human-readable JSON output. Implies **-j**.
> > +
> > +EXAMPLES
> > +========
> > +**# bpftool btf dump id 1226**
> > +::
> > +
> > + [1] PTR '(anon)' type_id=2
> > + [2] STRUCT 'dummy_tracepoint_args' size=16 vlen=2
> > + 'pad' type_id=3 bits_offset=0
> > + 'sock' type_id=4 bits_offset=64
> > + [3] INT 'long long unsigned int' size=8 bits_offset=0 nr_bits=64 encoding=(none)
> > + [4] PTR '(anon)' type_id=5
> > + [5] FWD 'sock' fwd_kind=union
> > +
> > +This gives an example of default output for all supported BTF kinds.
> > +
> > +**$ cat prog.c**
> > +::
> > +
> > + struct fwd_struct;
> > +
> > + enum my_enum {
> > + VAL1 = 3,
> > + VAL2 = 7,
> > + };
> > +
> > + typedef struct my_struct my_struct_t;
> > +
> > + struct my_struct {
> > + const unsigned int const_int_field;
> > + int bitfield_field: 4;
> > + char arr_field[16];
> > + const struct fwd_struct *restrict fwd_field;
> > + enum my_enum enum_field;
> > + volatile my_struct_t *typedef_ptr_field;
> > + };
> > +
> > + union my_union {
> > + int a;
> > + struct my_struct b;
> > + };
> > +
> > + struct my_struct struct_global_var __attribute__((section("data_sec"))) = {
> > + .bitfield_field = 3,
> > + .enum_field = VAL1,
> > + };
> > + int global_var __attribute__((section("data_sec"))) = 7;
> > +
> > + __attribute__((noinline))
> > + int my_func(union my_union *arg1, int arg2)
> > + {
> > + static int static_var __attribute__((section("data_sec"))) = 123;
> > + static_var++;
> > + return static_var;
> > + }
> > +
> > +**$ bpftool btf dump file prog.o**
> > +::
> > +
> > + [1] PTR '(anon)' type_id=2
> > + [2] UNION 'my_union' size=48 vlen=2
> > + 'a' type_id=3 bits_offset=0
> > + 'b' type_id=4 bits_offset=0
> > + [3] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
> > + [4] STRUCT 'my_struct' size=48 vlen=6
> > + 'const_int_field' type_id=5 bits_offset=0
> > + 'bitfield_field' type_id=3 bits_offset=32 bitfield_size=4
> > + 'arr_field' type_id=8 bits_offset=40
> > + 'fwd_field' type_id=10 bits_offset=192
> > + 'enum_field' type_id=14 bits_offset=256
> > + 'typedef_ptr_field' type_id=15 bits_offset=320
> > + [5] CONST '(anon)' type_id=6
> > + [6] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none)
> > + [7] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
> > + [8] ARRAY '(anon)' type_id=7 index_type_id=9 nr_elems=16
> > + [9] INT '__ARRAY_SIZE_TYPE__' size=4 bits_offset=0 nr_bits=32 encoding=(none)
> > + [10] RESTRICT '(anon)' type_id=11
> > + [11] PTR '(anon)' type_id=12
> > + [12] CONST '(anon)' type_id=13
> > + [13] FWD 'fwd_struct' fwd_kind=union
> > + [14] ENUM 'my_enum' size=4 vlen=2
> > + 'VAL1' val=3
> > + 'VAL2' val=7
> > + [15] PTR '(anon)' type_id=16
> > + [16] VOLATILE '(anon)' type_id=17
> > + [17] TYPEDEF 'my_struct_t' type_id=4
> > + [18] FUNC_PROTO '(anon)' ret_type_id=3 vlen=2
> > + 'arg1' type_id=1
> > + 'arg2' type_id=3
> > + [19] FUNC 'my_func' type_id=18
> > + [20] VAR 'struct_global_var' type_id=4, linkage=global-alloc
> > + [21] VAR 'global_var' type_id=3, linkage=global-alloc
> > + [22] VAR 'my_func.static_var' type_id=3, linkage=static
> > + [23] DATASEC 'data_sec' size=0 vlen=3
> > + type_id=20 offset=0 size=48
> > + type_id=21 offset=0 size=4
> > + type_id=22 offset=52 size=4
> > +
> > +The following commands print BTF types associated with specified map's key,
> > +value, both key and value, and all BTF types, respectively. By default, both
> > +key and value types will be printed.
>
> This kind of info should go into the command's description (although I
> don't mind if we also repeat it here).
Yeah, I added specification above, but also left examples.
>
> > +
> > +**# bpftool btf dump map id 123 key**
> > +
> > +::
> > +
> > + [39] TYPEDEF 'u32' type_id=37
> > +
> > +**# bpftool btf dump map id 123 value**
> > +
> > +::
> > +
> > + [86] PTR '(anon)' type_id=87
> > +
> > +**# bpftool btf dump map id 123 kv**
> > +
> > +::
> > +
> > + [39] TYPEDEF 'u32' type_id=37
> > + [86] PTR '(anon)' type_id=87
> > +
> > +**# bpftool btf dump map id 123 all**
> > +
> > +::
> > +
> > + [1] PTR '(anon)' type_id=0
> > + .
> > + .
> > + .
> > + [2866] ARRAY '(anon)' type_id=52 index_type_id=51 nr_elems=4
> > +
> > +All the standard ways to specify map or program is supported:
>
> s/is/are/
Eagle eye :)
>
> > +
> > +**# bpftool btf dump map id 123**
> > +
> > +**# bpftool btf dump map pinned /sys/fs/bpf/map_name**
> > +
> > +**# bpftool btf dump prog id 456**
> > +
> > +**# bpftool btf dump prog tag b88e0a09b1d9759d**
> > +
> > +**# bpftool btf dump prog pinned /sys/fs/bpf/prog_name**
> > +
> > +SEE ALSO
> > +========
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-04-25 22:25 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20190425165539.3317350-1-andriin@fb.com>
2019-04-25 19:20 ` [PATCH v3 bpf-next 0/4] add btf dumping to bpftool Quentin Monnet
2019-04-25 21:53 ` Andrii Nakryiko
[not found] ` <20190425165539.3317350-2-andriin@fb.com>
2019-04-25 19:20 ` [PATCH v3 bpf-next 1/4] bpftool: add ability to dump BTF types Quentin Monnet
2019-04-25 22:00 ` Andrii Nakryiko
[not found] ` <20190425165539.3317350-3-andriin@fb.com>
2019-04-25 19:20 ` [PATCH v3 bpf-next 2/4] bpftool/docs: add btf sub-command documentation Quentin Monnet
2019-04-25 22:24 ` Andrii Nakryiko
[not found] ` <20190425165539.3317350-4-andriin@fb.com>
2019-04-25 19:21 ` [PATCH v3 bpf-next 3/4] bpftool: add bash completions for btf command Quentin Monnet
[not found] ` <20190425165539.3317350-5-andriin@fb.com>
2019-04-25 19:21 ` [PATCH v3 bpf-next 4/4] bpftool: fix indendation in bash-completion/bpftool Quentin Monnet
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.