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: https://github.com/NixOS/nixpkgs/pull/195934

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

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'".

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.

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.

I often need to use bpftool on systems where it is not installed and cannot be installed. With this Dockerfile I can build and push a container image containing bpftool:

     $ docker build -f Dockerfile -t bpftool .

And use it on systems without bpftool:

     $ docker run --rm -ti --privileged --pid=host bpftool prog

cc @mauriciovasquezbernal

program by name

bpftool was limiting the length of names to BPF_OBJ_NAME_LEN.

Since https://github.com/libbpf/bpftool/commit/61833a284f48b90f6802c141c8356de64bb41e10 we can get the full program name from BTF.

This diffs remove the restriction of name length when running bpftool prog show name ${name}.

Test: Tested against some internal program names that were longer than BPF_OBJ_NAME_LEN, here a redacted example of what was ran to test.

$ sudo bpftool prog show name some_long_program_name
Error: can't parse name
$ sudo ./bpftool prog show name some_long_program_name
123456789: tracing  name some_long_program_name  tag taghexa  gpl ....
...
...
...

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?

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 \

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.

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

Pull latest libbpf from mirror and sync bpftool repo with kernel, up to the commits used for libbpf sync. This is an automatic update performed by calling the sync script from this repo:

$ ./scripts/sync-kernel.sh . <path/to/>linux

Additionally, add the relevant feature detection probe for the LLVM library which is now the default for disassembling JIT-compiled programs, and update the CI workflow accordingly.

https://github.com/libbpf/bpftool/blob/43b5daa16a4b8afd71bba491950b54219fc35988/src/cgroup.c#L235-L245 prog_attach_flags is the latest field in uapi but not exist in older kernel
https://github.com/torvalds/linux/blob/7d2a07b769330c34b4deabeed939325c77a7ec2f/include/uapi/linux/bpf.h#L1400-L1407 and in kernel it will ensure all fields after it's last field(prog_cnt) must be zero

/* 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.

clang \
        -I. \
        -I/home/ubuntu/bpf/bpftool/include/uapi/ \
        -I/home/ubuntu/bpf/bpftool/src/bootstrap/libbpf/include \
        -g -O2 -Wall -target bpf -c skeleton/pid_iter.bpf.c -o pid_iter.bpf.o
skeleton/pid_iter.bpf.c:47:14: error: incomplete definition of type 'struct bpf_perf_link'
        perf_link = container_of(link, struct bpf_perf_link, link);
                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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.