Giter VIP home page Giter VIP logo

libbpf-sys's Introduction

libbpf Github Actions Builds & Tests Coverity CodeQL OSS-Fuzz Status Read the Docs

This is the official home of the libbpf library.

Please use this Github repository for building and packaging libbpf and when using it in your projects through Git submodule.

Libbpf authoritative source code is developed as part of bpf-next Linux source tree under tools/lib/bpf subdirectory and is periodically synced to Github. As such, all the libbpf changes should be sent to BPF mailing list, please don't open PRs here unless you are changing Github-specific parts of libbpf (e.g., Github-specific Makefile).

Libbpf and general BPF usage questions

Libbpf documentation can be found here. It's an ongoing effort and has ways to go, but please take a look and consider contributing as well.

Please check out libbpf-bootstrap and the companion blog post for the examples of building BPF applications with libbpf. libbpf-tools are also a good source of the real-world libbpf-based tracing tools.

See also "BPF CO-RE reference guide" for the coverage of practical aspects of building BPF CO-RE applications and "BPF CO-RE" for general introduction into BPF portability issues and BPF CO-RE origins.

All general BPF questions, including kernel functionality, libbpf APIs and their application, should be sent to [email protected] mailing list. You can subscribe to it here and search its archive here. Please search the archive before asking new questions. It very well might be that this was already addressed or answered before.

[email protected] is monitored by many more people and they will happily try to help you with whatever issue you have. This repository's PRs and issues should be opened only for dealing with issues pertaining to specific way this libbpf mirror repo is set up and organized.

Building libbpf

libelf is an internal dependency of libbpf and thus it is required to link against and must be installed on the system for applications to work. pkg-config is used by default to find libelf, and the program called can be overridden with PKG_CONFIG.

If using pkg-config at build time is not desired, it can be disabled by setting NO_PKG_CONFIG=1 when calling make.

To build both static libbpf.a and shared libbpf.so:

$ cd src
$ make

To build only static libbpf.a library in directory build/ and install them together with libbpf headers in a staging directory root/:

$ cd src
$ mkdir build root
$ BUILD_STATIC_ONLY=y OBJDIR=build DESTDIR=root make install

To build both static libbpf.a and shared libbpf.so against a custom libelf dependency installed in /build/root/ and install them together with libbpf headers in a build directory /build/root/:

$ cd src
$ PKG_CONFIG_PATH=/build/root/lib64/pkgconfig DESTDIR=/build/root make install

BPF CO-RE (Compile Once โ€“ Run Everywhere)

Libbpf supports building BPF CO-RE-enabled applications, which, in contrast to BCC, do not require Clang/LLVM runtime being deployed to target servers and doesn't rely on kernel-devel headers being available.

It does rely on kernel to be built with BTF type information, though. Some major Linux distributions come with kernel BTF already built in:

  • Fedora 31+
  • RHEL 8.2+
  • OpenSUSE Tumbleweed (in the next release, as of 2020-06-04)
  • Arch Linux (from kernel 5.7.1.arch1-1)
  • Manjaro (from kernel 5.4 if compiled after 2021-06-18)
  • Ubuntu 20.10
  • Debian 11 (amd64/arm64)

If your kernel doesn't come with BTF built-in, you'll need to build custom kernel. You'll need:

  • pahole 1.16+ tool (part of dwarves package), which performs DWARF to BTF conversion;
  • kernel built with CONFIG_DEBUG_INFO_BTF=y option;
  • you can check if your kernel has BTF built-in by looking for /sys/kernel/btf/vmlinux file:
$ ls -la /sys/kernel/btf/vmlinux
-r--r--r--. 1 root root 3541561 Jun  2 18:16 /sys/kernel/btf/vmlinux

To develop and build BPF programs, you'll need Clang/LLVM 10+. The following distributions have Clang/LLVM 10+ packaged by default:

  • Fedora 32+
  • Ubuntu 20.04+
  • Arch Linux
  • Ubuntu 20.10 (LLVM 11)
  • Debian 11 (LLVM 11)
  • Alpine 3.13+

Otherwise, please make sure to update it on your system.

The following resources are useful to understand what BPF CO-RE is and how to use it:

Distributions

Distributions packaging libbpf from this mirror:

Benefits of packaging from the mirror over packaging from kernel sources:

  • Consistent versioning across distributions.
  • No ties to any specific kernel, transparent handling of older kernels. Libbpf is designed to be kernel-agnostic and work across multitude of kernel versions. It has built-in mechanisms to gracefully handle older kernels, that are missing some of the features, by working around or gracefully degrading functionality. Thus libbpf is not tied to a specific kernel version and can/should be packaged and versioned independently.
  • Continuous integration testing via GitHub Actions.
  • Static code analysis via LGTM and Coverity.

Package dependencies of libbpf, package names may vary across distros:

  • zlib
  • libelf

libbpf distro packaging status

bpf-next to Github sync

All the gory details of syncing can be found in scripts/sync-kernel.sh script. See SYNC.md for instruction.

Some header files in this repo (include/linux/*.h) are reduced versions of their counterpart files at bpf-next's tools/include/linux/*.h to make compilation successful.

License

This work is dual-licensed under BSD 2-clause license and GNU LGPL v2.1 license. You can choose between one of them if you use this work.

SPDX-License-Identifier: BSD-2-Clause OR LGPL-2.1

libbpf-sys's People

Contributors

alexforster avatar anakryiko avatar arilou avatar benfogle avatar chris-morgan avatar d-e-s-o avatar danielocfb avatar danobi avatar dansiemon avatar ehfive avatar gdetal avatar ghglavan avatar ilink avatar javierhonduco avatar jfernandez avatar jirutka avatar mdaverde avatar mmullin-halcyon avatar notgull avatar saschagrunert avatar vlrpl avatar willfindlay avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

libbpf-sys's Issues

Crate versioning scheme requires all dependencies to use exactly same libbpf-sys version

I want to use both redbpf crate to load BPF programs and xsk-rs to handle packets on user-space side. I even initiated moving redbpf crate from using it's own libbpf bindings to using libbpf-sys. But now I still have a problem: redpbf and xsk-rs use different versions of libbpf-sys: ^0.6.1-2 and ^0.6.0-1 respectively.
Usually '^version' notation lets Cargo to choose newer version for both, but prerelease suffix, if I understand correctly, prevents it.

So, how can I use several crates depending on libbpf-sys? Requiring all of dependant crates to use exactly same version of libbpf-sys doesn't seem like a solution, any future update of any of crates will break my build.

Failed to link statically with `-C target-feature=+crt-static` and `--target`

I'm working on an experimental ebpf implementation in conmon-rs, a container runtime monitor written in Rust: containers/conmon-rs#926

I'm not able to link the application statically anymore when using libbpf-rs, which directly depends on libbpf-sys, because of the error:

Running `rustc --crate-name libbpf_sys --edition=2018 /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-sys-1.0.4+v1.0.1/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --crate-type staticlib --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C debug-assertions=off --cfg 'feature="static"' -C metadata=a3f0ad521523a73e -C extra-filename=-a3f0ad521523a73e --out-dir /home/runner/work/conmon-rs/conmon-rs/target/release/deps -L dependency=/home/runner/work/conmon-rs/conmon-rs/target/release/deps --cap-lints allow -L native=/home/runner/work/conmon-rs/conmon-rs/target/release/build/libbpf-sys-a01c0f94146cf298/out -l static=elf -l static=z -l static=bpf`

error: could not find native static library `elf`, perhaps an -L flag is missing?

error: could not compile `libbpf-sys` due to previous error

Caused by:
  process didn't exit successfully: `rustc --crate-name libbpf_sys --edition=2018 /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-sys-1.0.4+v1.0.1/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --crate-type staticlib --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C debug-assertions=off --cfg 'feature="static"' -C metadata=a3f0ad521523a73e -C extra-filename=-a3f0ad521523a73e --out-dir /home/runner/work/conmon-rs/conmon-rs/target/release/deps -L dependency=/home/runner/work/conmon-rs/conmon-rs/target/release/deps --cap-lints allow -L native=/home/runner/work/conmon-rs/conmon-rs/target/release/build/libbpf-sys-a01c0f94146cf298/out -l static=elf -l static=z -l static=bpf` (exit status: 1)

It looks like that the RUSTFLAGS are being reset for this crate, but for others they got passed correctly, for example when looking into the build logs:

Running `rustc --crate-name clap --edition=2021 /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-3.2.22/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=z -C linker-plugin-lto -C codegen-units=1 -C debuginfo=2 --cfg 'feature="atty"' --cfg 'feature="cargo"' --cfg 'feature="clap_derive"' --cfg 'feature="color"' --cfg 'feature="default"' --cfg 'feature="deprecated"' --cfg 'feature="derive"' --cfg 'feature="env"' --cfg 'feature="once_cell"' --cfg 'feature="std"' --cfg 'feature="strsim"' --cfg 'feature="suggestions"' --cfg 'feature="termcolor"' --cfg 'feature="terminal_size"' --cfg 'feature="wrap_help"' -C metadata=4ceed62849ae43cd -C extra-filename=-4ceed62849ae43cd --out-dir /home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps -L dependency=/home/runner/work/conmon-rs/conmon-rs/target/release/deps --extern atty=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libatty-22b7da72fe42b183.rmeta --extern bitflags=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libbitflags-6cb1025d00e25f61.rmeta --extern clap_derive=/home/runner/work/conmon-rs/conmon-rs/target/release/deps/libclap_derive-00e157025f887d45.so --extern clap_lex=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libclap_lex-2b215555cb1ffb97.rmeta --extern indexmap=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libindexmap-7a358f6b01a7a487.rmeta --extern once_cell=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libonce_cell-66a71340f1f3f5d8.rmeta --extern strsim=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libstrsim-dbf9aece6da0347b.rmeta --extern termcolor=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libtermcolor-6e0510c9f30bb93d.rmeta --extern terminal_size=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libterminal_size-21e8b1454d21cbd2.rmeta --extern textwrap=/home/runner/work/conmon-rs/conmon-rs/target/x86_64-unknown-linux-gnu/release/deps/libtextwrap-3512bba442108cbc.rmeta --cap-lints allow -C target-feature=+crt-static -L /usr/lib/x86_64-linux-gnu -L src/backend/linux_raw/arch/outline/release`

https://github.com/containers/conmon-rs/actions/runs/3573239142/jobs/6007068777

We build the static binary by cross compiling and pre-setting RUSTFLAGS="-C target-feature=+crt-static -L /usr/lib/x86_64-linux-gnu" cargo build -v --release --target x86_64-unknown-linux-gnu --features static

All dependencies are in place in our CI, but it still cannot pickup the static libraries from /usr/lib/x86_64-linux-gnu because the RUSTFLAGS are unset. Do you have any idea what we can do about this?

Could not find native static library elf, perhaps an -L flag is missing? (using static feature)

cargo build -v --features static

Output:

       Fresh cfg_aliases v0.1.1
       Fresh libc v0.2.154
       Fresh cfg-if v1.0.0
       Fresh bitflags v2.5.0
       Fresh pkg-config v0.3.30
       Fresh cc v1.0.97
       Fresh nix v0.28.0
   Compiling libbpf-sys v1.4.1+v1.4.0 (/home/kes/libbpf-sys)
     Running `rustc --crate-name libbpf_sys --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=104 --crate-type lib --crate-type staticlib --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="static"' --cfg 'feature="static-libbpf"' --cfg 'feature="static-libelf"' --cfg 'feature="static-zlib"' --cfg 'feature="vendored-libbpf"' -C metadata=e8b69177a174d00c -C extra-filename=-e8b69177a174d00c --out-dir /home/kes/libbpf-sys/target/debug/deps -C incremental=/home/kes/libbpf-sys/target/debug/incremental -L dependency=/home/kes/libbpf-sys/target/debug/deps -L native=/home/kes/libbpf-sys/target/debug/build/libbpf-sys-ac808a735e3172a4/out -L native=/home/kes/libbpf-sys/target/debug/deps -L native=/home/kes/libbpf-sys/target/debug -L native=/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib -l static=elf -l static=z -l static=bpf`
error: could not find native static library `elf`, perhaps an -L flag is missing?

error: could not compile `libbpf-sys` (lib) due to 1 previous error

Caused by:
  process didn't exit successfully: `rustc --crate-name libbpf_sys --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=104 --crate-type lib --crate-type staticlib --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="static"' --cfg 'feature="static-libbpf"' --cfg 'feature="static-libelf"' --cfg 'feature="static-zlib"' --cfg 'feature="vendored-libbpf"' -C metadata=e8b69177a174d00c -C extra-filename=-e8b69177a174d00c --out-dir /home/kes/libbpf-sys/target/debug/deps -C incremental=/home/kes/libbpf-sys/target/debug/incremental -L dependency=/home/kes/libbpf-sys/target/debug/deps -L native=/home/kes/libbpf-sys/target/debug/build/libbpf-sys-ac808a735e3172a4/out -L native=/home/kes/libbpf-sys/target/debug/deps -L native=/home/kes/libbpf-sys/target/debug -L native=/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib -l static=elf -l static=z -l static=bpf` (exit status: 1)

Environment

  • OS: Arch Linux x86_64
  • Kernel: 6.8.9-arch1-2

could not find native static library elf, perhaps an -L flag is missing? (using static feature)

Original Issue: libbpf/libbpf-rs#515


Cannot build the project using the static feature.

Cargo.toml

[...]
libbpf-rs = { version = "0.21.1", features = ["static"] }
[...]

Error:

error: could not find native static library `elf`, perhaps an -L flag is missing?

error: could not compile `libbpf-sys` (lib) due to previous error

Caused by:
  process didn't exit successfully: `CARGO=/home/akshat/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/cargo CARGO_CRATE_NAME=libbpf_sys CARGO_MANIFEST_DIR=/home/akshat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libbpf-sys-1.2.1+v1.2.0 CARGO_PKG_AUTHORS='Alex Forster <[email protected]>:Dan Siemon <[email protected]>:Daniel Xu <[email protected]>' CARGO_PKG_DESCRIPTION='Rust bindings to libbpf from the Linux kernel' CARGO_PKG_HOMEPAGE='https://github.com/libbpf/libbpf-sys' CARGO_PKG_LICENSE=BSD-2-Clause CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=libbpf-sys CARGO_PKG_README=README.md CARGO_PKG_REPOSITORY='https://github.com/libbpf/libbpf-sys' CARGO_PKG_RUST_VERSION='' CARGO_PKG_VERSION=1.2.1+v1.2.0 CARGO_PKG_VERSION_MAJOR=1 CARGO_PKG_VERSION_MINOR=2 CARGO_PKG_VERSION_PATCH=1 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/home/akshat/wrkspc/ebpf-collector/target/debug/deps:/home/akshat/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib:/home/akshat/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib' OUT_DIR=/home/akshat/wrkspc/ebpf-collector/target/debug/build/libbpf-sys-c0bc7f46411bb923/out /home/akshat/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/rustc --crate-name libbpf_sys --edition=2018 /home/akshat/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libbpf-sys-1.2.1+v1.2.0/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=145 --crate-type lib --crate-type staticlib --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="static"' -C metadata=d2ad6cf3be166f7b -C extra-filename=-d2ad6cf3be166f7b --out-dir /home/akshat/wrkspc/ebpf-collector/target/debug/deps -L dependency=/home/akshat/wrkspc/ebpf-collector/target/debug/deps --cap-lints warn -L native=/home/akshat/wrkspc/ebpf-collector/target/debug/build/libbpf-sys-c0bc7f46411bb923/out -L native=/home/akshat/wrkspc/ebpf-collector/target/debug/deps -L native=/home/akshat/wrkspc/ebpf-collector/target/debug -L native=/home/akshat/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib -L native=/home/akshat/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib -l static=elf -l static=z -l static=bpf` (exit status: 1)

struct perf_event_attr seems to be wrong

Hi,

Looking at the definition of perf_event_attr it seems wrong compared to what it should be
#[repr(C)] #[derive(Debug, Default, Copy, Clone)] pub struct perf_event_attr { pub _address: u8, }

Where in fact it's

           struct perf_event_attr {
               __u32 type;                 /* Type of event */
               __u32 size;                 /* Size of attribute structure */
               __u64 config;               /* Type-specific configuration */

               union {
                   __u64 sample_period;    /* Period of sampling */
                   __u64 sample_freq;      /* Frequency of sampling */
               };

               __u64 sample_type;  /* Specifies values included in sample */
               __u64 read_format;  /* Specifies values returned in read */

               __u64 disabled       : 1,   /* off by default */
                     inherit        : 1,   /* children inherit it */
                     pinned         : 1,   /* must always be on PMU */
                     exclusive      : 1,   /* only group on PMU */
                     exclude_user   : 1,   /* don't count user */
                     exclude_kernel : 1,   /* don't count kernel */
                     exclude_hv     : 1,   /* don't count hypervisor */
                     exclude_idle   : 1,   /* don't count when idle */
                     mmap           : 1,   /* include mmap data */
                     comm           : 1,   /* include comm data */
                     freq           : 1,   /* use freq, not period */
                     inherit_stat   : 1,   /* per task counts */
                     enable_on_exec : 1,   /* next exec enables */
                     task           : 1,   /* trace fork/exit */
                     watermark      : 1,   /* wakeup_watermark */
                     precise_ip     : 2,   /* skid constraint */
                     mmap_data      : 1,   /* non-exec mmap data */
                     sample_id_all  : 1,   /* sample_type all events */
                     exclude_host   : 1,   /* don't count in host */
                     exclude_guest  : 1,   /* don't count in guest */
                     exclude_callchain_kernel : 1,
                                           /* exclude kernel callchains */
                     exclude_callchain_user   : 1,
                                           /* exclude user callchains */
                     mmap2          :  1,  /* include mmap with inode data */
                     comm_exec      :  1,  /* flag comm events that are
                                              due to exec */
                     use_clockid    :  1,  /* use clockid for time fields */
                     context_switch :  1,  /* context switch data */
                     write_backward :  1,  /* Write ring buffer from end
                                              to beginning */
                     namespaces     :  1,  /* include namespaces data */
                     ksymbol        :  1,  /* include ksymbol events */
                     bpf_event      :  1,  /* include bpf events */
                     aux_output     :  1,  /* generate AUX records
                                              instead of events */
                     cgroup         :  1,  /* include cgroup events */
                     text_poke      :  1,  /* include text poke events */

                     __reserved_1   : 30;

               union {
                   __u32 wakeup_events;    /* wakeup every n events */
                   __u32 wakeup_watermark; /* bytes before wakeup */
               };

               __u32     bp_type;          /* breakpoint type */

               union {
                   __u64 bp_addr;          /* breakpoint address */
                   __u64 kprobe_func;      /* for perf_kprobe */
                   __u64 uprobe_path;      /* for perf_uprobe */
                   __u64 config1;          /* extension of config */
               };

               union {
                   __u64 bp_len;           /* breakpoint length */
                   __u64 kprobe_addr;      /* with kprobe_func == NULL */
                   __u64 probe_offset;     /* for perf_[k,u]probe */
                   __u64 config2;          /* extension of config1 */
               };
               __u64 branch_sample_type;   /* enum perf_branch_sample_type */
               __u64 sample_regs_user;     /* user regs to dump on samples */
               __u32 sample_stack_user;    /* size of stack to dump on
                                              samples */
               __s32 clockid;              /* clock to use for time fields */
               __u64 sample_regs_intr;     /* regs to dump on samples */
               __u32 aux_watermark;        /* aux bytes before wakeup */
               __u16 sample_max_stack;     /* max frames in callchain */
               __u16 __reserved_2;         /* align to u64 */

           };

Build error

version: 0.5.0-2

error[E0063]: missing fields `__bindgen_padding_0` and `__bindgen_padding_1` in initializer of `bpf_object_open_opts`
  --> src/bpf/object.rs:41:9
   |
41 |         libbpf_sys::bpf_object_open_opts {
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `__bindgen_padding_0` and `__bindgen_padding_1`

For more information about this error, try `rustc --explain E0063`.

why are these paddings explicit? it is a breaking change that makes CI broken. please consider using another versioning scheme to avoid this kind of problems.

0.6.1-1 can't be built with rebuild.sh

$ ./rebuild.sh
[+] Building 251.3s (9/9) FINISHED
 => [internal] load build definition from Dockerfile                                                                    0.0s
 => => transferring dockerfile: 1.57kB                                                                                  0.0s
 => [internal] load .dockerignore                                                                                       0.0s
 => => transferring context: 2B                                                                                         0.0s
 => [internal] load metadata for docker.io/amd64/ubuntu:focal                                                           3.0s
 => [1/5] FROM docker.io/amd64/ubuntu:focal@sha256:57df66b9fc9ce2947e434b4aa02dbe16f6685e20db0c170917d4a1962a5fe6a9     4.7s
 => => resolve docker.io/amd64/ubuntu:focal@sha256:57df66b9fc9ce2947e434b4aa02dbe16f6685e20db0c170917d4a1962a5fe6a9     0.0s
 => => sha256:ea362f368469f909a95f9a6e54ebe0121ce0a8e3c30583dd9c5fb35b14544dec 28.57MB / 28.57MB                        3.3s
 => => sha256:57df66b9fc9ce2947e434b4aa02dbe16f6685e20db0c170917d4a1962a5fe6a9 529B / 529B                              0.0s
 => => sha256:d13c942271d66cb0954c3ba93e143cd253421fe0772b8bed32c4c0077a546d4d 1.46kB / 1.46kB                          0.0s
 => => extracting sha256:ea362f368469f909a95f9a6e54ebe0121ce0a8e3c30583dd9c5fb35b14544dec                               1.2s
 => [2/5] WORKDIR /usr/local/src/libbpf-sys                                                                             0.1s
 => [3/5] RUN  export DEBIAN_FRONTEND=noninteractive;  apt-get -q update;  apt-get -q install -y curl build-essential  65.6s
 => [4/5] RUN  curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --default-toolchain stable;     29.7s
 => [5/5] RUN  source $HOME/.cargo/env;  cargo install --git https://github.com/rust-lang/rust-bindgen --rev 2aed6b0  141.1s
 => exporting to image                                                                                                  7.0s
 => => exporting layers                                                                                                 7.0s
 => => writing image sha256:c69eaacaaeedab7597f5bee00acbaa5991961d174fc9a9f7179aec0cfb30a698                            0.0s
 => => naming to docker.io/library/libbpf-sys-builder                                                                   0.0s

Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them
/usr/local/src/libbpf-sys/bindings.h:8:10: fatal error: 'libbpf/include/uapi/linux/if_link.h' file not found
/usr/local/src/libbpf-sys/bindings.h:8:10: fatal error: 'libbpf/include/uapi/linux/if_link.h' file not found, err: true
thread 'main' panicked at 'Unable to generate bindings: ()', src/main.rs:52:36
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Bindgen unexpectedly panicked
This may be caused by one of the known-unsupported things (https://rust-lang.github.io/rust-bindgen/cpp.html), please modify the bindgen flags to work around it as described in https://rust-lang.github.io/rust-bindgen/cpp.html
Otherwise, please file an issue at https://github.com/rust-lang/rust-bindgen/issues/new

Enable Static aarch64 compilation in the CI

CI exists for aarch64, however the author of the recent static changes (aka me) did not update the CI to run a build aarch64 with static.

This led to a required hotfix (c043865)

I will start work on this tomorrow evening.

Test that `libbpf-rs` compiles without error in CI

Right now, there are no tests beyond ensuring that libbpf_set_print can be called. This ensures that something hasn't gone horribly wrong, but it doesn't do much to prevent API breakage.

In libbpf/libbpf-rs#303, a minor release of libbpf-sys broke libbpf-rs because bindgen's default behavior changed. This would have been prevented if we somehow tested compiling libbpf-rs in CI, but I don't know enough about GitHub CI to implement that.

Build fails with file not found error panic

Trying to compile libbpf-sys 0.4.0-2 on Ubuntu 21.04. Here is a skeleton Cargo.toml that illustrates the issue on my system:

[package]
name = "foo"
version = "0.1.0"
edition = "2018"

[dependencies]
libbpf-sys = { version = "0.4.0-2" }

cargo build trace with RUST_BACKTRACE=1:

   Compiling libbpf-sys v0.4.0-2
error: failed to run custom build command for `libbpf-sys v0.4.0-2`

Caused by:
  process didn't exit successfully: `/tmp/foo/target/debug/build/libbpf-sys-fa6170e7fd760d00/build-script-build` (exit status: 101)
  --- stderr
  thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', /home/cody/.cargo/registry/src/github.com-1ecc6299db9ec823/libbpf-sys-0.4.0-2/build.rs:44:14
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/std/src/panicking.rs:515:5
     1: core::panicking::panic_fmt
               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/panicking.rs:92:14
     2: core::result::unwrap_failed
               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/result.rs:1355:5
     3: core::result::Result<T,E>::unwrap
               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/result.rs:1037:23
     4: build_script_build::main
               at ./build.rs:34:22
     5: core::ops::function::FnOnce::call_once
               at /rustc/a178d0322ce20e33eac124758e837cbd80a6f633/library/core/src/ops/function.rs:227:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

zlib and libelf dependencies on my system:

pkg-config --modversion zlib
1.2.11
pkg-config --modversion libelf
0.183

Let me know if I can provide any more information that could be used to reproduce. Resolving #20 might give a better picture

Clarification on the metadata in semvar version

Hi, I want to ask about the metadata in the semvar version since it produces the warning:

version requirement 1.1.1+v1.0.1 for dependency libbpf-sys includes semver metadata which will be ignored, removing the metadata is recommended to avoid confusion

If I understand this correctly, the +v1.0.1 is for information only to indicate to a human reader which libbpf version is used from upstream. Therefore, if needed, we can safely remove the metadata version from cargo manifest?

Show example to build

Recently, I was trying out building libbpf-rs ran into libbpf/libbpf-rs#300

I think it would be nice to show which system packages need to be installed, e.g. on Ubuntu

sudo apt install libelf-dev pkgconf

where pkgconf provides pkg-config executable.

Incorrect libbpf submodule published to crates.io for version 1.0.2+v1.0.1

The version of libbpf published to crates.io is version 1.0.0 not 1.0.1

Steps to reproduce:
$ mkdir download_area
$ cd download_area
$ curl -L https://crates.io/api/v1/crates/libbpf-sys/1.0.2+v1.0.1/download --output libbpf-sys.tar.gz
$ tar xzvf libbpf-sys.tar.gz
$ cat libbpf-sys-1.0.2+v1.0.1/libbpf/src/Makefile | grep LIBBPF_PATCH_VERSION

Expected Result:
LIBBPF_PATCH_VERSION := 1

Actual Result
LIBBPF_PATCH_VERSION := 0

NOTES:

Observe that in libbpf.h the change described here: libbpf/libbpf@5847387
is not available.

Because libbpf is at version 1.0.0, but the bindings.rs was generated for version 1.0.1 the bpf_object_open_opts structure is incorrect.

No support for 32-bit?

The new explicit padding is explicit for 64bit data alignment. Can eBPF used on 32bit machines?

I'm sorry, but I do not have a 32 bit machine to verify whether this is an issue or not.

bpf_tc_opts should use the MaybeUninit method of creating a default

Similar to bpf_tc_hook, struct bpf_tc_opts needs to be fully zeroed or the BPF verifier will complain "libbpf: bpf_tc_opts has non-zero extra bytes"

client code can do this work, but it would be nice if the libbpf-sys library did it for the clients

Question: How does rust-bindgen determine that bpf_tc_hooks needs a MaybeUninit zero method, while bpf_tc_opts does not?

AArch64 support broken?

With redbpf, we recently started migrating to libbpf-sys from our own wrapper that preceded this project. However, our CI quickly flagged up an error on aarch64, which I think we can only address by partially reverting to generating our own bindings to certain calls.

My question is whether we're mis-using libbpf-sys, or is this a known limitation? I couldn't find other than AMD64 compatibility in the CI.

I'd be happy to dig deeper on this, just wanted to get a confirmation if you have any experience on this front.

Thanks!

32 bit build broken?

In response to libbpf/libbpf-rs#500 I created danielocfb@5e93a20 to make sure that libbpf-sys is also tested in a 32 bit setting. That seems to blow up pretty prominently immediately: https://github.com/danielocfb/libbpf-sys/actions/runs/5479871661/jobs/9982296567

--> src/bindings.rs:512:49
    |
512 | pub const PERF_TXN_ABORT_MASK: _bindgen_ty_52 = 18446744069414584320;
    |                                                 ^^^^^^^^^^^^^^^^^^^^
    |
    = note: the literal `18446744069414584320` does not fit into the type `u32` whose range is `0..=4294967295`
    = note: `#[deny(overflowing_literals)]` on by default

error: literal out of range for `u32`
    --> src/bindings.rs:1478:53
     |
1478 | pub const PERF_CONTEXT_HV: perf_callchain_context = 18446744073709551584;
     |                                                     ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709551584` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:1479:57
     |
1479 | pub const PERF_CONTEXT_KERNEL: perf_callchain_context = 18446744073709551488;
     |                                                         ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709551488` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:1480:55
     |
1480 | pub const PERF_CONTEXT_USER: perf_callchain_context = 18446744073709551104;
     |                                                       ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709551104` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:1481:56
     |
1481 | pub const PERF_CONTEXT_GUEST: perf_callchain_context = 18446744073709549568;
     |                                                        ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709549568` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:1482:63
     |
1482 | pub const PERF_CONTEXT_GUEST_KERNEL: perf_callchain_context = 18446744073709549440;
     |                                                               ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709549440` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:1483:61
     |
1483 | pub const PERF_CONTEXT_GUEST_USER: perf_callchain_context = 18446744073709549056;
     |                                                             ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709549056` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:1484:54
     |
1484 | pub const PERF_CONTEXT_MAX: perf_callchain_context = 18446744073709547521;
     |                                                      ^^^^^^^^^^^^^^^^^^^^
     |
     = note: the literal `18446744073709547521` does not fit into the type `u32` whose range is `0..=4294967295`

error: literal out of range for `u32`
    --> src/bindings.rs:2908:47
     |
2908 | pub const BPF_F_CTXLEN_MASK: _bindgen_ty_65 = 4503[59](https://github.com/danielocfb/libbpf-sys/actions/runs/5479871661/jobs/9982296567#step:8:60)5332403200;
     |                                               ^^^^^^^^^^^^^^^^
     |
     = note: the literal `4503595332403200` does not fit into the type `u32` whose range is `0..=4294967295`

error: could not compile `libbpf-sys` (lib) due to 9 previous errors

Any idea how we can adjust the type of those constants, by any chance? I haven't found any knobs.

Missing libbpf v0.2 symbols

I'm getting linker errors when I use the v0.2 libbpf-sys from crates.io:

  = note: /bin/ld: /home/daniel/dev/libbpf-rs/target/debug/deps/cargo_libbpf-e1881abc62d2e476.3pzy2gabm1c6gb6f.rcgu.o: in function `cargo_libbpf::btf::btf::Btf::new':
          /home/daniel/dev/libbpf-rs/libbpf-cargo/src/btf/btf.rs:61: undefined reference to `btf__set_endianness'
          collect2: error: ld returned 1 exit status

I don't get the error when I use a local checkout of libbpf-sys:

$ cat Cargo.toml
[...]

[dependencies]
libbpf-sys = { path = "/home/daniel/dev/libbpf-sys" }

$  nm ./target/debug/build/libbpf-sys-37d4aafae3a38032/out/libbpf.a | rg endian
00000000000016c0 T btf__endianness
00000000000016d0 T btf__set_endianness

Since I don't see any special git submodule initialization in the build script, I wonder if the libbpf sources uploaded to crates.io are just whatever you have checked out at time of cargo publish.

If that's the case, if it possible you didn't update the libbpf submodule before cargo publishing? Just a guess.

libbpf vendoring

So libbpf source is currently vendored. And at libbpf-sys build time, cargo builds libbpf, builds shim for the inline functions, builds libbpf-sys rust bits, then links it all together.

I'm wondering why/if libbpf needs to be vendored. IIUC some *-sys libraries link against the system installed library (eg ncurses https://github.com/jeaye/ncurses-rs/blob/master/build.rs#L11).

The reason I bring this up is b/c I noticed that building CO-RE bpf programs requires libbpf headers so you'll need to install libbpf-devel anyways. And then you get some skew between libbpf-devel and libbpf-sys-built libbpf.

Add a feature to statically link elfutils and zlib

๐Ÿ‘‹ Hi folks! First of all, thanks so much for this crate!

I am trying to create a statically linked binary, rbperf, that depends on libbpf-rs.

The first thing I bumped into was that while libbpf is linked statically, elfutils and zlib aren't. With this patch to add this feature in libbpf-sys (javierhonduco@4a6b367) and exposing it in libbpf-rs (javierhonduco/libbpf-rs@b66a96e) I am able to depend on fewer dynamic libraries, and getting a bit closer to the fully static goal.

Before

[javierhonduco@computer-2 rbperf]$ ldd target/debug/rbperf
	linux-vdso.so.1 (0x00007ffca76d3000)
	libelf.so.1 => /lib/libelf.so.1 (0x00007fbfb7f5a000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fbfb7f40000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbfb7f20000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fbfb7e42000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fbfb7c41000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fbfb87cf000)

After

[javierhonduco@computer rbperf]$ ldd target/debug/rbperf
	linux-vdso.so.1 (0x00007ffde392c000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6dd42ff000)
	libm.so.6 => /lib64/libm.so.6 (0x00007f6dd4221000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f6dd4020000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6dd4ba0000)

Would you be open to the idea of having this implemented? If so, I would be more than happy to open a PR ๐Ÿ˜„

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.