{"id":15029963,"url":"https://github.com/libbpf/libbpf-bootstrap","last_synced_at":"2025-05-14T12:10:07.291Z","repository":{"id":37033843,"uuid":"303065613","full_name":"libbpf/libbpf-bootstrap","owner":"libbpf","description":"Scaffolding for BPF application development with libbpf and BPF CO-RE","archived":false,"fork":false,"pushed_at":"2025-04-10T22:09:36.000Z","size":4106,"stargazers_count":1217,"open_issues_count":15,"forks_count":319,"subscribers_count":26,"default_branch":"master","last_synced_at":"2025-04-12T14:15:09.239Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"CMake","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/libbpf.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2020-10-11T07:25:56.000Z","updated_at":"2025-04-12T04:01:55.000Z","dependencies_parsed_at":"2024-11-11T18:26:46.404Z","dependency_job_id":"9ed35bf9-71e5-472e-9755-70e2539d9f6b","html_url":"https://github.com/libbpf/libbpf-bootstrap","commit_stats":{"total_commits":189,"total_committers":49,"mean_commits":3.857142857142857,"dds":0.7777777777777778,"last_synced_commit":"8e6d30ec7aabecf02595b0c9c6fe4760188a203f"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/libbpf%2Flibbpf-bootstrap","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/libbpf%2Flibbpf-bootstrap/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/libbpf%2Flibbpf-bootstrap/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/libbpf%2Flibbpf-bootstrap/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/libbpf","download_url":"https://codeload.github.com/libbpf/libbpf-bootstrap/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254140749,"owners_count":22021219,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-09-24T20:12:06.467Z","updated_at":"2025-05-14T12:10:07.227Z","avatar_url":"https://github.com/libbpf.png","language":"CMake","funding_links":[],"categories":["eBPF Workflow: Tools and Utilities","eBPF 工作流：工具和实用程序","CMake"],"sub_categories":["libbpf"],"readme":"# libbpf-bootstrap: demo BPF applications\n\n[![Github Actions](https://github.com/libbpf/libbpf-bootstrap/actions/workflows/build.yml/badge.svg)](https://github.com/libbpf/libbpf-bootstrap/actions/workflows/build.yml)\n[![Github Actions](https://github.com/libbpf/libbpf-bootstrap/actions/workflows/build-android.yml/badge.svg)](https://github.com/libbpf/libbpf-bootstrap/actions/workflows/build-android.yml)\n\n## minimal\n\n`minimal` is just that – a minimal practical BPF application example. It\ndoesn't use or require BPF CO-RE, so should run on quite old kernels. It\ninstalls a tracepoint handler which is triggered once every second. It uses\n`bpf_printk()` BPF helper to communicate with the world. To see it's output,\nread `/sys/kernel/debug/tracing/trace_pipe` file as a root:\n\n```shell\n$ cd examples/c\n$ make minimal\n$ sudo ./minimal\n$ sudo cat /sys/kernel/debug/tracing/trace_pipe\n           \u003c...\u003e-3840345 [010] d... 3220701.101143: bpf_trace_printk: BPF triggered from PID 3840345.\n           \u003c...\u003e-3840345 [010] d... 3220702.101265: bpf_trace_printk: BPF triggered from PID 3840345.\n```\n\n`minimal` is great as a bare-bones experimental playground to quickly try out\nnew ideas or BPF features.\n\n## minimal_ns\n\n`minimal_ns` is as same as `minimal` but for namespaced environments.\n`minimal` would not work in environments that have namespace, like containers,\nor WSL2, because the perceived pid of the process in the namespace is not the\nactual pid of the process. For executing `minimal` in namespaced environments\nyou need to use `minimal_ns` instead.\n\n```shell\n$ cd examples/c\n$ make minimal_ns\n$ sudo ./minimal_ns\n$ sudo cat /sys/kernel/debug/tracing/trace_pipe\n           \u003c...\u003e-3840345 [022] d...1  8804.331204: bpf_trace_printk: BPF triggered from PID 9087.\n           \u003c...\u003e-3840345 [022] d...1  8804.331215: bpf_trace_printk: BPF triggered from PID 9087.\n```\n\n## minimal_Legacy\n\nThis version of `minimal` is modified to allow running on even older kernels\nthat do not allow global variables. bpf_printk uses global variables unless\nBPF_NO_GLOBAL_DATA is defined before including bpf_helpers.h. Additionally,\nthe global variable my_pid has been replaced with an array of one element to\nhold the process pid.\n\n```\n$ cd examples/c\n$ make minimal_legacy\n$ sudo ./minimal_legacy\n$ sudo cat /sys/kernel/debug/tracing/trace_pipe\n  minimal_legacy-52030 [001] .... 491227.784078: 0x00000001: BPF triggered from PID 52030.\n  minimal_legacy-52030 [001] .... 491228.840571: 0x00000001: BPF triggered from PID 52030.\n  minimal_legacy-52030 [001] .... 491229.841643: 0x00000001: BPF triggered from PID 52030.\n  minimal_legacy-52030 [001] .... 491230.842432: 0x00000001: BPF triggered from PID 52030.\n```\n\n## bootstrap\n\n`bootstrap` is an example of a simple (but realistic) BPF application. It\ntracks process starts (`exec()` family of syscalls, to be precise) and exits\nand emits data about filename, PID and parent PID, as well as exit status and\nduration of the process life. With `-d \u003cmin-duration-ms\u003e` you can specify\nminimum duration of the process to log. In such mode process start\n(technically, `exec()`) events are not output (see example output below).\n\n`bootstrap` was created in the similar spirit as\n[libbpf-tools](https://github.com/iovisor/bcc/tree/master/libbpf-tools) from\nBCC package, but is designed to be more stand-alone and with simpler Makefile\nto simplify adoption to user's particular needs. It demonstrates the use of\ntypical BPF features:\n  - cooperating BPF programs (tracepoint handlers for process `exec` and `exit`\n    events, in this particular case);\n  - BPF map for maintaining the state;\n  - BPF ring buffer for sending data to user-space;\n  - global variables for application behavior parameterization.\n  - it utilizes BPF CO-RE and vmlinux.h to read extra process information from\n    kernel's `struct task_struct`.\n\n`bootstrap` is intended to be the starting point for your own BPF application,\nwith things like BPF CO-RE and vmlinux.h, consuming BPF ring buffer data,\ncommand line arguments parsing, graceful Ctrl-C handling, etc. all taken care\nof for you, which are crucial but mundane tasks that are no fun, but necessary\nto be able to do anything useful. Just copy/paste and do simple renaming to get\nyourself started.\n\nHere's an example output in minimum process duration mode:\n\n```shell\n$ sudo ./bootstrap -d 50\nTIME     EVENT COMM             PID     PPID    FILENAME/EXIT CODE\n19:18:32 EXIT  timeout          3817109 402466  [0] (126ms)\n19:18:32 EXIT  sudo             3817117 3817111 [0] (259ms)\n19:18:32 EXIT  timeout          3817110 402466  [0] (264ms)\n19:18:33 EXIT  python3.7        3817083 1       [0] (1026ms)\n19:18:38 EXIT  python3          3817429 3817424 [1] (60ms)\n19:18:38 EXIT  sh               3817424 3817420 [0] (79ms)\n19:18:38 EXIT  timeout          3817420 402466  [0] (80ms)\n19:18:43 EXIT  timeout          3817610 402466  [0] (70ms)\n19:18:43 EXIT  grep             3817619 3817617 [1] (271ms)\n19:18:43 EXIT  timeout          3817609 402466  [0] (321ms)\n19:18:44 EXIT  iostat           3817585 3817531 [0] (3006ms)\n19:18:44 EXIT  tee              3817587 3817531 [0] (3005ms)\n...\n```\n\n## uprobe\n\n`uprobe` is an example of dealing with user-space entry and exit (return) probes,\n`uprobe` and `uretprobe`, in libbpf lingo. It attaches `uprobe` and `uretprobe`\nBPF programs to its own functions (`uprobed_add()` and `uprobed_sub()`) and logs input arguments\nand return result, respectively, using `bpf_printk()` macro. The user-space\nfunction is triggered once every second:\n\n```shell\n$ sudo ./uprobe\nlibbpf: loading object 'uprobe_bpf' from buffer\n...\nSuccessfully started!\n...........\n```\n\nYou can see `uprobe` demo output in `/sys/kernel/debug/tracing/trace_pipe`:\n```shell\n$ sudo cat /sys/kernel/debug/tracing/trace_pipe\n          uprobe-1809291 [007] .... 4017233.106596: 0: uprobed_add ENTRY: a = 0, b = 1\n          uprobe-1809291 [007] .... 4017233.106605: 0: uprobed_add EXIT: return = 1\n          uprobe-1809291 [007] .... 4017233.106606: 0: uprobed_sub ENTRY: a = 0, b = 0\n          uprobe-1809291 [007] .... 4017233.106607: 0: uprobed_sub EXIT: return = 0\n          uprobe-1809291 [007] .... 4017234.106694: 0: uprobed_add ENTRY: a = 1, b = 2\n          uprobe-1809291 [007] .... 4017234.106697: 0: uprobed_add EXIT: return = 3\n          uprobe-1809291 [007] .... 4017234.106700: 0: uprobed_sub ENTRY: a = 1, b = 1\n          uprobe-1809291 [007] .... 4017234.106701: 0: uprobed_sub EXIT: return = 0\n```\n\n## usdt\n\n`usdt` is an example of dealing with USDT probe. It attaches USDT BPF programs to\nthe [libc:setjmp](https://www.gnu.org/software/libc/manual/html_node/Non_002dlocal-Goto-Probes.html) probe, which is triggered by calling `setjmp` in user-space program once per second and logs USDT arguments using `bpf_printk()` macro:\n\n```shell\n$ sudo ./usdt\nlibbpf: loading object 'usdt_bpf' from buffer\n...\nSuccessfully started!\n...........\n```\n\nYou can see `usdt` demo output in `/sys/kernel/debug/tracing/trace_pipe`:\n```shell\n$ sudo cat /sys/kernel/debug/tracing/trace_pipe\n            usdt-1919077 [005] d..21 537310.886092: bpf_trace_printk: USDT auto attach to libc:setjmp: arg1 = 55d03d6a42a0, arg2 = 0, arg3 = 55d03d65e54e\n            usdt-1919077 [005] d..21 537310.886105: bpf_trace_printk: USDT manual attach to libc:setjmp: arg1 = 55d03d6a42a0, arg2 = 0, arg3 = 55d03d65e54e\n            usdt-1919077 [005] d..21 537311.886214: bpf_trace_printk: USDT auto attach to libc:setjmp: arg1 = 55d03d6a42a0, arg2 = 0, arg3 = 55d03d65e54e\n            usdt-1919077 [005] d..21 537311.886227: bpf_trace_printk: USDT manual attach to libc:setjmp: arg1 = 55d03d6a42a0, arg2 = 0, arg3 = 55d03d65e54e\n```\n\n## fentry\n\n`fentry` is an example that uses fentry and fexit BPF programs for tracing. It\nattaches `fentry` and `fexit` traces to `do_unlinkat()` which is called when a\nfile is deleted and logs the return value, PID, and filename to the\ntrace pipe.\n\nImportant differences, compared to kprobes, are improved performance and\nusability. In this example, better usability is shown with the ability to\ndirectly dereference pointer arguments, like in normal C, instead of using\nvarious read helpers. The big distinction between **fexit** and **kretprobe**\nprograms is that fexit one has access to both input arguments and returned\nresult, while kretprobe can only access the result.\n\nfentry and fexit programs are available starting from 5.5 kernels.\n\n```shell\n$ sudo ./fentry\nlibbpf: loading object 'fentry_bpf' from buffer\n...\nSuccessfully started!\n..........\n```\n\nThe `fentry` output in `/sys/kernel/debug/tracing/trace_pipe` should look\nsomething like this:\n\n```shell\n$ sudo cat /sys/kernel/debug/tracing/trace_pipe\n              rm-9290    [004] d..2  4637.798698: bpf_trace_printk: fentry: pid = 9290, filename = test_file\n              rm-9290    [004] d..2  4637.798843: bpf_trace_printk: fexit: pid = 9290, filename = test_file, ret = 0\n              rm-9290    [004] d..2  4637.798698: bpf_trace_printk: fentry: pid = 9290, filename = test_file2\n              rm-9290    [004] d..2  4637.798843: bpf_trace_printk: fexit: pid = 9290, filename = test_file2, ret = 0\n```\n\n## kprobe\n\n`kprobe` is an example of dealing with kernel-space entry and exit (return)\nprobes, `kprobe` and `kretprobe`, in libbpf lingo. It attaches `kprobe` and\n`kretprobe` BPF programs to the `do_unlinkat()` function and logs the PID,\nfilename, and return result, respectively, using `bpf_printk()` macro.\n\n```shell\n$ sudo ./kprobe\nlibbpf: loading object 'kprobe_bpf' from buffer\n...\nSuccessfully started!\n...........\n```\n\nThe `kprobe` demo output in `/sys/kernel/debug/tracing/trace_pipe` should look\nsomething like this:\n\n```shell\n$ sudo cat /sys/kernel/debug/tracing/trace_pipe\n              rm-9346    [005] d..3  4710.951696: bpf_trace_printk: KPROBE ENTRY pid = 9346, filename = test1\n              rm-9346    [005] d..4  4710.951819: bpf_trace_printk: KPROBE EXIT: ret = 0\n              rm-9346    [005] d..3  4710.951852: bpf_trace_printk: KPROBE ENTRY pid = 9346, filename = test2\n              rm-9346    [005] d..4  4710.951895: bpf_trace_printk: KPROBE EXIT: ret = 0\n```\n\n## xdp\n\n`xdp` is an example written in Rust (using libbpf-rs). It attaches to\nthe ingress path of networking device and logs the size of each packet,\nreturning `XDP_PASS` to allow the packet to be passed up to the kernel’s\nnetworking stack.\n\n```shell\n$ sudo ./target/release/xdp 1\n..........\n```\n\nThe `xdp` output in `/sys/kernel/debug/tracing/trace_pipe` should look\nsomething like this:\n\n```shell\n$ sudo cat /sys/kernel/debug/tracing/trace_pipe\n           \u003c...\u003e-823887  [000] d.s1 602386.079100: bpf_trace_printk: packet size: 75\n           \u003c...\u003e-823887  [000] d.s1 602386.079141: bpf_trace_printk: packet size: 66\n           \u003c...\u003e-2813507 [000] d.s1 602386.696702: bpf_trace_printk: packet size: 77\n           \u003c...\u003e-2813507 [000] d.s1 602386.696735: bpf_trace_printk: packet size: 66\n```\n\n## tc\n\n`tc` (short for Traffic Control) is an example of handling ingress network traffics.\nIt creates a qdisc on the `lo` interface and attaches the `tc_ingress` BPF program to it.\nIt reports the metadata of the IP packets that coming into the `lo` interface.\n\n```shell\n$ sudo ./tc\n...\nSuccessfully started! Please run `sudo cat /sys/kernel/debug/tracing/trace_pipe` to see output of the BPF program.\n......\n```\n\nThe `tc` output in `/sys/kernel/debug/tracing/trace_pipe` should look\nsomething like this:\n\n```\n$ sudo cat /sys/kernel/debug/tracing/trace_pipe\n            node-1254811 [007] ..s1 8737831.671074: 0: Got IP packet: tot_len: 79, ttl: 64\n            sshd-1254728 [006] ..s1 8737831.674334: 0: Got IP packet: tot_len: 79, ttl: 64\n            sshd-1254728 [006] ..s1 8737831.674349: 0: Got IP packet: tot_len: 72, ttl: 64\n            node-1254811 [007] ..s1 8737831.674550: 0: Got IP packet: tot_len: 71, ttl: 64\n```\n\n## profile\n\n`profile` is an example written in Rust and C using the\n[`blazesym`](https://github.com/libbpf/blazesym) symbolization library. It\nattaches to perf events, sampling on every processor periodically. It\nshows addresses, symbols, file names, and line numbers of stacktraces (if\navailable).\n\n```shell\n$ sudo ./target/release/profile\nCOMM: swapper/2 (pid=0) @ CPU 2\nKernel:\n0xffffffffb59141f8: mwait_idle_with_hints.constprop.0 @ 0xffffffffb59141b0+0x48\n0xffffffffb5f731ce: intel_idle @ 0xffffffffb5f731b0+0x1e\n0xffffffffb5c7bf09: cpuidle_enter_state @ 0xffffffffb5c7be80+0x89\n0xffffffffb5c7c309: cpuidle_enter @ 0xffffffffb5c7c2e0+0x29\n0xffffffffb516f57c: do_idle @ 0xffffffffb516f370+0x20c\n0xffffffffb516f829: cpu_startup_entry @ 0xffffffffb516f810+0x19\n0xffffffffb5075bfa: start_secondary @ 0xffffffffb5075ae0+0x11a\n0xffffffffb500015a: secondary_startup_64_no_verify @ 0xffffffffb5000075+0xe5\nNo Userspace Stack\n```\n\nC version and Rust version show the same content. Both of them use `blazesym`\nto symbolize stacktraces.\n\n## sockfilter\n\n`sockfilter` is an example of monitoring packet and dealing with `__sk_buff`\nstructure. It attaches `socket` BPF program to `sock_queue_rcv_skb()` function\nand retrieve information from `BPF_MAP_TYPE_RINGBUF`, then print\nprotocol, src IP, src port, dst IP, dst port in standard output.\nCurrently, most of the IPv4 protocols defined in `uapi/linux/in.h` are included,\nplease check `ipproto_mapping` of `examples/c/sockfilter.c` for the supported protocols.\n\n```shell\n$ sudo ./sockfilter -i \u003cinterface\u003e\ninterface:lo    protocol: UDP   127.0.0.1:51845(src) -\u003e 127.0.0.1:53(dst)\ninterface:lo    protocol: UDP   127.0.0.1:41552(src) -\u003e 127.0.0.1:53(dst)\n```\n\n## task_iter\n\n`task_iter` is an example of using [BPF Iterators](https://docs.kernel.org/bpf/bpf_iterators.html). \nThis example iterates over all tasks on the host and gets their pid, process name, \nkernel stack, and their state. Note: you can use BlazeSym to symbolize the kernel stacktraces \n(like in `profile`) but that code is omitted for simplicity.\n\n```shell\n$ sudo ./task_iter\nTask Info. Pid: 3647645. Process Name: TTLSFWorker59. Kernel Stack Len: 3. State: INTERRUPTIBLE\nTask Info. Pid: 1600495. Process Name: tmux: client. Kernel Stack Len: 6. State: INTERRUPTIBLE\nTask Info. Pid: 1600497. Process Name: tmux: server. Kernel Stack Len: 0. State: RUNNING\nTask Info. Pid: 1600498. Process Name: bash. Kernel Stack Len: 5. State: INTERRUPTIBLE\n```\n\n## lsm\n`lsm` serves as an illustrative example of utilizing [LSM BPF](https://docs.kernel.org/bpf/prog_lsm.html). In this example, the `bpf()` system call is effectively blocked. Once the `lsm` program is operational, its successful execution can be confirmed by using the `bpftool prog list` command.\n\n```shell\n$ sudo ./lsm\nlibbpf: loading object 'lsm_bpf' from buffer\n...\nSuccessfully started! Please run `sudo cat /sys/kernel/debug/tracing/trace_pipe` to see output of the BPF programs.\n..........\n```\n\nThe output from `lsm` in `/sys/kernel/debug/tracing/trace_pipe` is expected to resemble the following:\n\n````shell\n$ sudo cat /sys/kernel/debug/tracing/trace_pipe\n         bpftool-70646   [002] ...11 279318.416393: bpf_trace_printk: LSM: block bpf() worked\n         bpftool-70646   [002] ...11 279318.416532: bpf_trace_printk: LSM: block bpf() worked\n         bpftool-70646   [002] ...11 279318.416533: bpf_trace_printk: LSM: block bpf() worked\n````\n\nWhen the `bpf()` system call gets blocked, the `bpftool prog list` command yields the following output:\n\n```shell\n$ sudo bpftool prog list\nError: can't get next program: Operation not permitted\n```\n\n# Building\n\nlibbpf-bootstrap supports multiple build systems that do the same thing.\nThis serves as a cross reference for folks coming from different backgrounds.\n\n## Install Dependencies\n\nYou will need `clang` (at least v11 or later), `libelf` and `zlib` to build\nthe examples, package names may vary across distros.\n\nOn Ubuntu/Debian, you need:\n```shell\n$ apt install clang libelf1 libelf-dev zlib1g-dev\n```\n\nOn CentOS/Fedora, you need:\n```shell\n$ dnf install clang elfutils-libelf elfutils-libelf-devel zlib-devel\n```\n## Getting the source code\n\nDownload the git repository and check out submodules:\n```shell\n$ git clone --recurse-submodules https://github.com/libbpf/libbpf-bootstrap\n```\n\n## C Examples\n\nMakefile build:\n\n```shell\n$ git submodule update --init --recursive       # check out libbpf\n$ cd examples/c\n$ make\n$ sudo ./bootstrap\nTIME     EVENT COMM             PID     PPID    FILENAME/EXIT CODE\n00:21:22 EXIT  python3.8        4032353 4032352 [0] (123ms)\n00:21:22 EXEC  mkdir            4032379 4032337 /usr/bin/mkdir\n00:21:22 EXIT  mkdir            4032379 4032337 [0] (1ms)\n00:21:22 EXEC  basename         4032382 4032381 /usr/bin/basename\n00:21:22 EXIT  basename         4032382 4032381 [0] (0ms)\n00:21:22 EXEC  sh               4032381 4032380 /bin/sh\n00:21:22 EXEC  dirname          4032384 4032381 /usr/bin/dirname\n00:21:22 EXIT  dirname          4032384 4032381 [0] (1ms)\n00:21:22 EXEC  readlink         4032387 4032386 /usr/bin/readlink\n^C\n```\n\nCMake build:\n\n```shell\n$ git submodule update --init --recursive       # check out libbpf\n$ mkdir build \u0026\u0026 cd build\n$ cmake ../examples/c\n$ make\n$ sudo ./bootstrap\n\u003c...\u003e\n```\n\nXMake build (Linux):\n\n```shell\n$ git submodule update --init --recursive       # check out libbpf\n$ cd examples/c\n$ xmake\n$ xmake run bootstrap\n```\n\nXMake build (Android):\n\n```shell\n$ git submodule update --init --recursive       # check out libbpf\n$ cd examples/c\n$ xmake f -p android\n$ xmake\n```\n\nInstall [Xmake](https://github.com/xmake-io/xmake)\n\n```shell\n$ bash \u003c(wget https://xmake.io/shget.text -O -)\n$ source ~/.xmake/profile\n```\n\n## Rust Examples\n\nInstall `libbpf-cargo`:\n```shell\n$ cargo install libbpf-cargo\n```\n\nBuild using `cargo`:\n```shell\n$ cd examples/rust\n$ cargo build --release\n$ sudo ./target/release/xdp 1\n\u003c...\u003e\n```\n\n# Troubleshooting\n\nLibbpf debug logs are quire helpful to pinpoint the exact source of problems,\nso it's usually a good idea to look at them before starting to debug or\nposting question online.\n\n`./minimal` is always running with libbpf debug logs turned on.\n\nFor `./bootstrap`, run it in verbose mode (`-v`) to see libbpf debug logs:\n\n```shell\n$ sudo ./bootstrap -v\nlibbpf: loading object 'bootstrap_bpf' from buffer\nlibbpf: elf: section(2) tp/sched/sched_process_exec, size 384, link 0, flags 6, type=1\nlibbpf: sec 'tp/sched/sched_process_exec': found program 'handle_exec' at insn offset 0 (0 bytes), code size 48 insns (384 bytes)\nlibbpf: elf: section(3) tp/sched/sched_process_exit, size 432, link 0, flags 6, type=1\nlibbpf: sec 'tp/sched/sched_process_exit': found program 'handle_exit' at insn offset 0 (0 bytes), code size 54 insns (432 bytes)\nlibbpf: elf: section(4) license, size 13, link 0, flags 3, type=1\nlibbpf: license of bootstrap_bpf is Dual BSD/GPL\n...\n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flibbpf%2Flibbpf-bootstrap","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Flibbpf%2Flibbpf-bootstrap","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flibbpf%2Flibbpf-bootstrap/lists"}