bpftool iter only support the pin subcommands. It begs for a list subcommands. Not sure if this is completely necessary though, given that we can already see the iterators from bpftool prog. At least we've got the code for listing them already: if we want to add a bpftool iter list we can probably just reuse the code from bpftool prog list, filtering on program type.

This is gonna ruin the git blame, but we should really look into fixing the weird indentation in use for the detailed description of the commands in the doc. We currently have two tabs followed by two spaces for the body of the description, auto-indent in text editors don't like it and it's a pain for contributors.

I'm not aware of any particular reason for that other than that's how the doc was created in the first place.

Maybe just two tabs, or maybe just spaces - whatever. We need to make sure that the formatting of the rendered man page is preserved, though.

We have bash completion, but many users use Zsh nowadays.

Some other shells are in use as well (fish, ...), and could be candidates, although I'm not familiar with other completion systems.

Not sure if these would make it to the Linux repo, but alternatively we could host them on this mirror at least.

I'm seeing this error in some of our autobuilders test builds. I verified this error still exists as of version 51d4a12.

net.c: In function 'netlink_open':
net.c:110:36: error: 'NETLINK_EXT_ACK' undeclared (first use in this function); did you mean 'NETLINK_CAP_ACK'?
  110 |  if (setsockopt(sock, SOL_NETLINK, NETLINK_EXT_ACK,
      |                                    ^~~~~~~~~~~~~~~
      |                                    NETLINK_CAP_ACK

I have following map:

struct
{
  __uint(type, BPF_MAP_TYPE_RINGBUF);
  __uint(max_entries, MAX_ENTRIES);
} ring_map SEC(".maps");

under v7.0.0 it works, under v7.1.0 getting an error:
bpftool gen skeleton build/.gens/xxx/android/x86_64/release/rules/bpf/xxx.bpf.o -d -p

...
libbpf: map 'xxx': unsupported map linkage static.
{
    "error": "failed to open BPF object file: Operation not supported"
}

Similarly to what we do for program types, map types, helpers, and a few other components, we could look into dumping supported kfuncs with bpftool feature probe.

It is not clear yet what the probes would look like.

https://lore.kernel.org/bpf/[email protected]/

binutils changed the signature of init_disassemble_info(), which now causes
perf and bpftool to fail to compile (e.g. on debian unstable).

Relevant binutils commit: https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=60a3da00bd5407f07d64dff82a4dae98230dfaac

util/annotate.c: In function ‘symbol__disassemble_bpf’:
util/annotate.c:1765:9: error: too few arguments to function ‘init_disassemble_info’
 1765 |         init_disassemble_info(&info, s,
      |         ^~~~~~~~~~~~~~~~~~~~~
In file included from util/annotate.c:1718:
/usr/include/dis-asm.h:472:13: note: declared here
  472 | extern void init_disassemble_info (struct disassemble_info *dinfo, void *stream,
      |             ^~~~~~~~~~~~~~~~~~~~~

with equivalent failures in

tools/bpf/bpf_jit_disasm.c
tools/bpf/bpftool/jit_disasm.c

This is being discussed on the mailing list. See email thread for more details.

Code like bpf_printk("hello\n") will generate a section '.rodata.str1.1'

When I compile the above code with old version bpftool (the bpftool is installed by apt install in Ubuntu 20.10 kernel 5.8), the generated binary works well.

But when I use the same environment with the latest bpftool version to compile the same code, the generated binary report the error "libbpf: failed to find skeleton map '.rodata.str1.1'".

I don't think bpftool supports this at the moment.

Version:

bpftool --version
bpftool v6.7.0
using libbpf v0.7
features: libbpf_strict

This happens only in a 32-bit environment and not 64-bit. I have a BPF array with value that looks like this:

struct map_value {
   int a;
   int b;
   short c;
   bool d;
};

struct {
   __uint( type, BPF_MAP_TYPE_ARRAY );
   __uint( max_entries, 1 );
   __type( key, uint32_t );
   __type( value, struct map_value );
} my_map SEC( ".maps" );

bpftool map dump shows:

bpftool map dump name my_map --pretty
[{
        "key": ["0x00","0x00","0x00","0x00"
        ],
        "value": ["0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00","0x00"
        ],
        "formatted": {
            "key": 0,
            "value": {
                "a": 0,
                "b": 0,
                "c": 0,
                "d": true
            }
        }
    }
]

The raw bytes look right (this is the initial state of the array) but the formatted output is wrong.

We could add an option to dump inner maps when dumping an outer map-of-map with bpftool.

Building bpftool statically, as explained in the README.md, should work:

• With CFLAGS=--static
• With LLVM for dumping JIT-compiled programs, provided static LLVM has been built and installed
• Not with libbfd without additional efforts, see also #66

We should:

• Figure out what's missing for building statically against libbfd
• Add CI tests for static builds (llvm, libbfd, none of them).

If a bpf program has a global variable of type: long, its skeleton will include
a bss map that will have a field for this variable. The long variable in BPF is
64-bit. if we are working on a 32-bit machine, the generated skeleton has to
compile for that machine where long is 32-bit.

More context: https://lore.kernel.org/bpf/CANk7y0joRFw2F4iAuN9r-dWWMvOmbFZz_J4rhGhgVFjdnxPTYw@mail.gmail.com/

/* helper macro to check that unused fields 'union bpf_attr' are zero */
#define CHECK_ATTR(CMD) \
	memchr_inv((void *) &attr->CMD##_LAST_FIELD + \
		   sizeof(attr->CMD##_LAST_FIELD), 0, \
		   sizeof(*attr) - \
		   offsetof(union bpf_attr, CMD##_LAST_FIELD) - \
		   sizeof(attr->CMD##_LAST_FIELD)) != NULL

#define BPF_PROG_QUERY_LAST_FIELD query.prog_cnt

static int bpf_prog_query(const union bpf_attr *attr,
			  union bpf_attr __user *uattr)
{
	if (!capable(CAP_NET_ADMIN))
		return -EPERM;
	if (CHECK_ATTR(BPF_PROG_QUERY))
		return -EINVAL;
         ...
}  

It seems the upstream kernel doesn't have the compatibility issue because libbpf/bpftool is as the part of it's source.

Makefile.feature may check requirement lib like as zlib,but if clang's version 11.0.0 it's not work well.
some code need escape character like \n you need add like that:

-        $(shell echo $(ZLIB_PROBE) | \
+        $(shell echo -e $(ZLIB_PROBE) | \
       $(CC) $(CFLAGS) -Wall -Werror $(LDFLAGS) -x c - -lz -S -o - >/dev/null 2>&1 \
     && echo 1)

or it output error like that:

<stdin>:1:18: error: extra tokens at end of #include directive [-Werror,-Wextra-tokens]
#include <zlib.h>\n int main(void) {  z_stream zs;      inflateInit(&zs);       return 0; }
                 ^
                 //
1 error generated.

and other echo need echo -e replace

Makefile.include need add EXTRA_WARNINGS in clang version is 11.0.0

      +        -Wno-unused-command-line-argument \

bpftool map event_pipe dumps data from a perf ring. We don't have any equivalent yet for BPF ring buffers.

Hi,
I am working on a small tool which needs to identify map type (HASH/ARRAY etc) from bpf programs. I have seen BTF which is able to provide type of the key and value of the map but not the type of the map itself (which is the value of the map type variable).
So what I want to ask is is there a way to identity the type of map being used by looking at the BPF programs.

Not sure if this is the correct place to ask this question, if not please let me know.
Thanks in advance.

Few minor improvements to keep tracking:

For human readable output dump "prog id %u" for progs and "link id %u" for links consistently. Currently some types dump just "id %u" and other use "prog_id %u" ("_").

The Documentation/bpftool-net.rst is in some cases overly specific in which order what is dumped (is it relevant for man page?) and examples could need a refresher.

Hi,

I compiled the https://github.com/vincentmli/XDPeriments/blob/master/RRL/Round1/xdp_rrl_per_ip.c to xdp_rrl_per_ip.o and also checked out bpftool v6.7.0 and compiled bpftool statically, then trying to load it on legacy old Ubuntu 16.04 with kernel 4.15.0-99, but got following error

./bpftool --legacy prog load xdp_rrl_per_ip.o xdp dev lo

libbpf: map 'state_map' (legacy): legacy map definitions are deprecated, use BTF-defined maps instead
libbpf: map 'state_map_v6' (legacy): legacy map definitions are deprecated, use BTF-defined maps instead
libbpf: map 'state_map': failed to create: Invalid argument(-22)
libbpf: failed to load object 'xdp_rrl_per_ip.o'
Error: failed to load object file

my intention is to run XDP program on the Ubuntu 16.04 kernel without BTF support, the map in the xdp_rrl_per_ip.c is not BTF defined map, the reason I use bpftool is that I could not find user space bpf loader that would work in Ubuntu 16.04 user space. is there way to workaround this with bpftool? I looked btfhub project, do I really need BTF?

./bpftool --version
./bpftool v6.7.0
using libbpf v0.7
features: libbpf_strict, skeletons

Detection of LLVM libraries for LLVM 16+ fails in the kernel repository, resulting in bpftool being compiled without the LLVM-based disassembler for JIT-compiled BPF programs.

Reported here: https://lore.kernel.org/lkml/CALS7K9V1j6ufrQ=6nGjyHQCWb7-YiqNdctBWk8og1gW_q4C4dA@mail.gmail.com/

See libbpf/ci#101 for context and blocker issue.

The GitHub mirror uses a different probe for LLVM libraries, and is not affected by this issue.

Context: https://lore.kernel.org/bpf/[email protected]/T/#t

Function mount_bpffs_for_pin() was initially written for getting files as arguments, so it tries to mount (when relevant) the bpffs on the parent directory of the file it gets.

When receiving a directory name instead, it still uses the parent directory, when it should instead:

1. If the dir exists and is bpffs, then: do nothing
2. If the dir exists but is not bpffs, then: mount the bpffs, but on the provided directory only, not its parent
3. If the dir does not exist, but its parent dir is bpffs, then: do nothing
4. If the dir does not exist and its parent is not bpffs, then: mount the bpffs on the provided directory, but this requires to create this dir first.

Is there a plan to drop the libbpf submodule, and/or to allow building bpftool against the stand-alone libbpf? Right now this requires modifications to the Makefile, making life of people trying to package bpftool harder than it needs to be. Also, the release tarball does not include libbpf, so it can't be built without extra actions.

Following the instructions in README.md, I used the command

 CFLAGS=--static make

hoping to compile and statically link the bpftool binary, however, the error I got it

/usr/bin/ld: cannot find -lelf
/usr/bin/ld: cannot find -lz
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status

I'm using a fedora:32 docker container to build. I'm guessing I need to install statically linked versions of libelf, libz and libc? I see libelf.so, libz.so and libc.so are all there in /usr/lib64. Where do I get libelf.a, libz.a, and libc.a? Not very familiar with statically linked libraries. Any help is appreciated!

Extract from man bpftool-map:

       bpftool map create     FILE type TYPE key KEY_SIZE value VALUE_SIZE
         entries MAX_ENTRIES name NAME [flags FLAGS] [inner_map MAP]
         [dev NAME]
       bpftool map dump       MAP
       bpftool map update     MAP [key DATA] [value VALUE] [UPDATE_FLAGS]

Instead of passing integer for FLAGS and UPDATE_FLAGS that are the sum of all relevant flags, we could support something more user-friendly as well, like a comma-separated list of flags: BPF_F_NO_PREALLOC,BPF_F_RDONLY,...

bpftool net attach can load only one XDP program to a network interface. We would make it work in a similar way to what xdp-loader does.

Someone reported an issue with binutils 2.40 (released mid-January 2023).

Reference: https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:B/bpftool/standard/x86_64

[   77s] gcc -O2 -W -Wall -Wextra -Wno-unused-parameter
    -Wno-missing-field-initializers -Wbad-function-cast
    -Wdeclaration-after-statement -Wformat-security -Wformat-y2k -Winit-self
    -Wmissing-declarations -Wmissing-prototypes -Wno-system-headers
    -Wold-style-definition -Wpacked -Wredundant-decls -Wstrict-prototypes
    -Wswitch-default -Wundef -Wwrite-strings -Wformat -Wno-type-limits
    -Wstrict-aliasing=3 -Wshadow -DPACKAGE='"bpftool"' -D__EXPORTED_HEADERS__ -I.
    -I/home/abuild/rpmbuild/BUILD/tools/bpf/bpftool/libbpf/include
    -I/home/abuild/rpmbuild/BUILD/kernel/bpf/
    -I/home/abuild/rpmbuild/BUILD/tools/include
    -I/home/abuild/rpmbuild/BUILD/tools/include/uapi -DDISASM_FOUR_ARGS_SIGNATURE
    -DDISASM_INIT_STYLED -DHAVE_LIBBFD_SUPPORT -DBPFTOOL_WITHOUT_SKELETONS  btf.o
    btf_dumper.o cfg.o cgroup.o common.o feature.o gen.o iter.o json_writer.o
    link.o main.o map.o map_perf_ring.o net.o netlink_dumper.o perf.o pids.o prog.o
    struct_ops.o tracelog.o xlated_dumper.o jit_disasm.o disasm.o
    /home/abuild/rpmbuild/BUILD/tools/bpf/bpftool/libbpf/libbpf.a -lelf -lz -lbfd
    -ldl -lopcodes -liberty -o bpftool
[   77s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc/x86_64-suse-linux/12/../../../../lib64/libbfd.a(elfxx-x86.o): in function `_bfd_x86_elf_write_sframe_plt':
[   77s] /home/abuild/rpmbuild/BUILD/binutils-2.40/build-dir/bfd/../../bfd/elfxx-x86.c:1977: undefined reference to `sframe_encoder_write'
[   77s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: /home/abuild/rpmbuild/BUILD/binutils-2.40/build-dir/bfd/../../bfd/elfxx-x86.c:1983: undefined reference to `sframe_encoder_free'
[   77s] /usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: /usr/lib64/gcc/x86_64-suse-linux/12/../../../../lib64/libbfd.a(elfxx-x86.o): in function `_bfd_x86_elf_create_sframe_plt':
[   77s] /home/abuild/rpmbuild/BUILD/binutils-2.40/build-dir/bfd/../../bfd/elfxx-x86.c:1874: undefined reference to `sframe_encode'

as seen, new binutils comes with a new library called sframe and the
aforementioned issue can be fixed by adding '-lsframe' to the command line.

Sounds like we'll need to add new probes to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/build/feature/Makefile#n246, and update bpftool's Makefile accordingly.

I don't know if this library comes with binutils-dev or if it needs to be installed separately. I haven't reproduced yet.

Context:

https://lore.kernel.org/all/CAEf4BzZMJGrRhNeQeWB0fRsuRYUv01aZGhvDeFV2o5zdpRbR-w@mail.gmail.com/

https://lore.kernel.org/bpf/CAEf4BzaFu_qFvwtE-=WLWM2YUirq5fKbbTGXVeNiqrARdLj+Vg@mail.gmail.com/T/#m01ccd9c263415fcabafbf831aefe7877312b2f48

Some prints use argv[0] as the name of the tool, e.g. bpftool --version. I don't like that.

I find it weird e.g. that the output should change depending on how you call the tool – via $PATH or by absolute path. But we even faced a practical issue with that: NixOS/nixpkgs#195934

So I suggest that you consider changing this. You can get inspired in the linked pull request or not.

TL;DR: When cross-compiling, host little-endian bootstrap bpftool cannot
open a big-endian ELF to generate a skeleton from it and build target
big-endian bpftool.

Long version: Currently, bpftool's Makefile compiles the
skeleton-related programs (skeletons/*.bpf.c) without paying attention
to the target architecture. When cross-compiling, say on a host with LE
for a target with BE, this leads to runtime failure on "bpftool prog
show", because bpftool cannot load the LE bytecode on the BE target
machine. This is Christophe's output here.

So the first fix is to make the Makefile aware of the target endianness
somehow, and to build this ELF with target endianness. But this is not
enough, because when (host) boostrap bpftool opens the ELF to generate
the skeleton from it before building the final (target) bpftool binary,
then bpf_object__check_endianness() in libbpf refuses to open the ELF if
endianness is not the same as on the host as seen here.

The way I see it, we'd need to make sure libbpf can work with ELFs of a
different endianness -- assuming that's doable -- and to pass it an
option to tell whether LE or BE is expected for a given ELF. Which in
turn would require bootstrap bpftool to be aware of the target
endianness.

https://lore.kernel.org/bpf/[email protected]/

root@DESKTOP-H3MBKRR:/home/lys/work/bpf# sudo bpftool prog load hello.o tracepoint
Error: can't mount BPF file system to pin the object (tracepoint): mount --make-private . failed: Invalid argument

is bpftool bug?

Output:

# bpftool feature probe | grep sockopt
eBPF program_type cgroup_sockopt is available
	- bpf_setsockopt
	- bpf_getsockopt
	- bpf_setsockopt
	- bpf_getsockopt
eBPF helpers supported for program type cgroup_sockopt:
	- bpf_setsockopt
	- bpf_getsockopt

Expected output:

# bpftool feature probe | grep sockopt
eBPF program_type cgroup_sockopt is available
	- bpf_setsockopt
	- bpf_getsockopt
eBPF helpers supported for program type cgroup_sockopt:

Version:

# bpftool --version
bpftool v5.10.140

Kernel Version:

# uname -r
5.10.0-14-amd64

The helper bpf_getsockopt did not get merged into kernel until 5.12 due to my research. Cilium is using bpftool to check whether this helper exist. On kernel 5.10, bpftool show this helper exist, so cilium tries to use this helper and crashed because it does not exist. I tried bpftool on kernel 5.4.214, it correctly show the absence of the helper.

From man bpftool-btf:

 BTF_SRC := { id BTF_ID | prog PROG | map MAP [{key | value | kv | all}] | file FILE }

We could support passing BTF objects by name as well, e.g. vmlinux or any module name.

make command in the docs file doesn't run successfully.

Environment: WSL2 (Ubuntu [uname -r gives 5.15.90.1-microsoft-standard-WSL2])
When I run "make install" in the "docs" sub-folder, it throws the following error:
Makefile:41: *** "rst2man not found, but required to generate man pages". Stop.

Following the discussion with Andrii on the BPF mailing list, we want to improve error messages by writing explicitly the name of the error returned from the kernel in addition to its interpretation, for example:

Error: can't get next program: [-EPERM] Operation not permitted

There's some work to do in libbpf (teaching libbpf_strerror_r() to do this), and then we could wrap error messages in bpftool to use that function.

Hi, I'm trying to compile bpftool in linux kernel 6.3 on ubuntu 22.04. When I do make I receive the following errors:

~mptcp_net-next/tools/bpf/bpftool$ make

Auto-detecting system features:
... clang-bpf-co-re: [ on ]
... llvm: [ on ]
... libcap: [ OFF ]
... libbfd: [ OFF ]

MKDIR /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/
make[1]: enter from the directory '/home/test2/mptcp_net-next/tools/lib/bpf'
GEN /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/bpf_helper_defs.h
MKDIR /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/staticobjs/
CC /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/staticobjs/libbpf.o

In file included from /usr/include/asm-generic/int-ll64.h:12,
from /usr/include/asm-generic/types.h:7,
from /usr/include/x86_64-linux-gnu/asm/types.h:1,
from /home/test2/mptcp_net-next/tools/include/linux/types.h:13,
from /home/test2/mptcp_net-next/tools/include/linux/compiler.h:105,
from /home/test2/mptcp_net-next/tools/include/linux/err.h:5,
from libbpf.c:29:

/home/test2/mptcp_net-next/tools/include/asm-generic/bitsperlong.h:14:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
14 | #error Inconsistent word size. Check asm/bitsperlong.h
| ^~~~~
make[2]: *** [/home/test2/mptcp_net-next/tools/build/Makefile.build:98: /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/staticobjs/libbpf.o] Error 1
make[1]: *** [Makefile:157: /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/staticobjs/libbpf-in.o] Error 2
make[1]: exits from the directory '/home/test2/mptcp_net-next/tools/lib/bpf'
make: *** [Makefile:46: /home/test2/mptcp_net-next/tools/bpf/bpftool/libbpf/libbpf.a] Error 2

Any advice?

This is a self-reminder to “revert” torvalds/linux@4b7ef71 (not in the GitHub mirror yet) and replace the /* fallthrough */ comment in btf_dumper.c with the new fallthrough macro, after its definition is available in bpf-next tree.

Seems like there is a minor issue in Makefile.feature:

make feature-libbfd=0 feature-libbfd-liberty=0 feature-libbfd-liberty-z=0
Makefile.feature:41: *** missing separator.  Stop.

The following change fixes it:

--- Makefile.feature.orig       2022-05-20 11:16:43.241156473 -0700
+++ Makefile.feature    2022-05-20 11:17:33.380310301 -0700
@@ -38,8 +38,8 @@
   feature-libbfd-liberty := \
     $(findstring 1,$(call libbfd_build,-lbfd -ldl -liberty))
   ifneq ($(feature-libbfd-liberty),1)
-    $(findstring 1,feature-libbfd-liberty-z := \
-      $(call libbfd_build,-lbfd -ldl -liberty -lz))
+    feature-libbfd-liberty-z := \
+      $(findstring 1,$(call libbfd_build,-lbfd -ldl -liberty -lz))
   endif
 endif
 HAS_LIBBFD := $(findstring 1, \

Some link types could be added here:

Side note: Are programs attached to XDP links displayed in bpftool net?

See discussion in #54.

No need to display an empty maps for types for which we know we can't display anything - apparently the BPF ring buffer, likely the perf event array maps too, maybe a few others. Bpftool should just tell it cannot dump these types.

On Ubuntu focal I see:

$ make
...                        libbfd: [ on  ]
...        disassembler-four-args: [ on  ]
...                          zlib: [ on  ]
...                        libcap: [ on  ]
...               clang-bpf-co-re: [ OFF ]

After looking in Makefile.features it is looking for BTF_KIND_VAR, but I don't see that:

$ clang --version
clang version 10.0.0-4ubuntu1
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

[~/scm/bpftool/src (master)]
$ printf '%s\n' 'struct s { int i; } __attribute__((preserve_access_index)); struct s foo;' | clang -g -target bpf -S -o - -x c -  | grep BTF_KIND_
        .long   1                       # BTF_KIND_STRUCT(id = 1)
        .long   5                       # BTF_KIND_INT(id = 2)

Am I not configured correctly or should this check be more loose?

Command bpftool perf list does not display all perf-related programs. It doesn't show programs attached through BPF links, only those that have an open FD. This should be documented.

In my notes, I also have a mention that writeable tracepoints are not displayed either. Because they use links? Should be investigated and clarified in the documentation.

We should really have a more robust CI for bpftool.

Current status

Build

• GitHub CI builds: Building bpftool on Ubuntu, running on PRs and pushes on this repository. Mostly help checking that everything seems in order when synchronising the mirror.
• test_bpftool_build.sh: Builds bpftool as part of BPF selftests (hence BPF CI). Ensures that basic build from a number of locations in the kernel repo and with or without passing an output directory still works as expected.

Selftests

Part of the BPF selftests (and running as part of the BPF CI).

• test_bpftool.py, test_bpftool.sh: Mostly about bpftool feature probe.
• test_bpftool_metadata.sh

Miscellaneous

• test_bpftool_synctypes.py: Checks that various definitions in kernel headers, bpftool sources, bpftool docs and bash completion remain in sync. Not part of BPF selftests, but explicitly run as part of the BPF CI.
• Some other workflows in the current repository, not directly related to the bpftool application.

Wish list

There is a variety of components that we would like to test. The list below is mostly a brain dump. Ideally, we want as much as possible as this testing to happen as part of the BPF CI, meaning we probably want to upstream it and make it part of the BPF selftests (Or have a dedicated repo for bpftool CI and see with BPF CI folks, to do something similar to libbpf's CI? Maybe for building bpftool, but testing that features work correctly should really go upstream).

Build

• Try various feature sets (LLVM library vs. libbfd, with and without the other features...).
• Try various kernel versions. In particular, we're having some issues when bpftool uses new definitions in skeletons for the BPF programs the binary relies on.
• Try various distros/arch. It would be nice to cover aarch64, also something big-endian.
• In the future: Windows?

Selftests

• Check that all supported program and map types remain supported, by trying to load minimal objects of each type. I had something in progress on a dedicated branch but I never finished it.

• Check that most/all commands behave as expected. This will require quite some work, because:

  • We must create a bunch of BPF programs (and related objects) that we can use for covering all BPF commands.
  • We must set up the host to be able to observe whatever we need to validate that the commands are working.
  • Everything we set up for introspection (or retrieving prog/map IDs etc.) should ideally not rely on bpftool itself (or libbpf)? So that if set up is broken we can still list objects. Although the alternatives to libbpf are mostly Go and Rust libraries and I don't see us introducing them in the CI.
  • We already have a lot of commands and options!

• A code coverage tool could be helpful at some point, if we manage to cover a significant portion of the command list.

Misc

• Simplify docs/sources to remove as much as possible the need to sync each time new types are added. Some work has been done in that direction already, but maybe we can improve more.
• Add tests for bash completion, likely based on what the project does (see tests/ and GitHub workflows).

I've not checked whether bpftool can dump a map protected by a spinlock, but I suspect it cannot (BPF_F_LOCK is likely required?). We should check and make it possible if it's not the case.

Support dumping BPF maps faster by using batch map processing when possible.

Attach types are using the legacy attach type names, but we switched to those used by libbpf in commit torvalds/linux@1ba5ad3. (Legacy attach type names are only kept for compatibility but are not longer recommended.) We should update the attach types in the doc.

make error build in clang 11.0.0 like that:
netlink_dumper.c:50:14: error: use of undeclared identifier 'XDP_ATTACHED_MULTI'
if (mode == XDP_ATTACHED_MULTI) {
^
netlink_dumper.c:55:24: error: use of undeclared identifier 'IFLA_XDP_SKB_PROG_ID'; did you mean 'IFLA_XDP_PROG_ID'?
xdp_dump_prog_id(tb, IFLA_XDP_SKB_PROG_ID, "generic", true);
^~~~~~~~~~~~~~~~~~~~
IFLA_XDP_PROG_ID
maybe miss if_link.h in usersapce?
like add libbpf that https://github.com/libbpf/libbpf/tree/master/include/uapi/linux

bpftool btf dump file /sys/kernel/btf/<object> is valid, but not documented in man bpftool-btf. The document only mentions that When specifying FILE, an ELF file is expected [...]. Documentation should be updated.

The command below can be used to dump the control flow graph on the program:

# bpftool prog dump xlated id <id> visual

(Example)

But as far as I remember (not 100% sure though) we don't have the C code lines on this graph. It would be helpful to have them, to better analyse the code.

Add a GitHub workflow to build and publish a new image (likely to ghcr.io) on pushes to the master branch, so that users can pull it directly.