Comments (8)
Hi and thanks for the report!
I'm not sure if this is a change in bpftool or libbpf that causes this error. As far as I know
.rodata.str1.1
has never really been supported by libbpf, I'm not sure why the string ends up in there and why your program was working with an earlier version.I would appreciate if you could please do the following:
- Confirm that you used the same clang/llvm version for the two tests (with both the old and the new bpftool versions),
Yes. Two tests used the same clang/llvm version.
- Specify your clang version,
Ubuntu clang version 11.0.0-2
Target: x86_64
My testing environment is Ubuntu 20.10 kernel version is 5.8.
- Provide a reproducer (a minimal eBPF program which fails to load with bpftool), and the command that you run to compile it.
Here is a simple eBPF program based on libbpf-bootstrap which can reproduce the error:
SEC("kprobe/vfs_read")
int BPF_KPROBE(vfs_read_entry)
{
bpf_printk("hello world\n");
return 0;
}
In the meantime, if you need your program to load, one workaround seems to be to declare the string const as a global, see this example.
Thanks for the example.
from bpftool.
Great, thanks for testing! I want to investigate more on this but didn't have time this week, and will be off for the next ten days or so.
Regarding your findings: I wonder if we're talking of the same thing. Was it on
kprobe.bpf.o
that you observe the.rodata.str1.1
section?
Yes.
When I compile with the libbpf 0.4 version, the generated binary fails. I run the command llvm-objdump --headers .output/xx.bpf.o
and see the .rodata.str1.1
section printed in the screen.
When I just update libbpf from 0.4 to latest version without modifying other content, the generated binary works well and the above command print .rodata
section instead of ordata.str1.1
.
The bpftool version is
bpftool v6.8.0
using libbpf v0.8
features: libbfd, libbpf_strict
I'm asking because libbpf is not involved in compiling from C into this file. It's only involved later, when parsing this ELF file to extract the eBPF bytecode and load it into the kernel. So the libbpf version should not have any influence on what sections are present in the ELF file - only on whether it can work with them when trying to parse and load. I didn't have time to check, but from the error you get,
failed to find skeleton map
, I wonder if this might come from the skeleton generated by bpftool rather than from the eBPF program itself. I'll need to dig into a it a bit more.
I agree with you. I am also curious why the libbpf version affects the .rodata.str1.1 section
from bpftool.
Hi and thanks for the report!
I'm not sure if this is a change in bpftool or libbpf that causes this error. As far as I know .rodata.str1.1
has never really been supported by libbpf, I'm not sure why the string ends up in there and why your program was working with an earlier version.
I would appreciate if you could please do the following:
- Confirm that you used the same clang/llvm version for the two tests (with both the old and the new bpftool versions),
- Specify your clang version,
- Provide a reproducer (a minimal eBPF program which fails to load with bpftool), and the command that you run to compile it.
In the meantime, if you need your program to load, one workaround seems to be to declare the string const as a global, see this example.
from bpftool.
I'm sorry, I don't manage to recreate the object file with the .rodata.str1.1
section. Would you be able to attach the ELF file directly please?
I tried to:
- Install a Ubuntu 20.10 VM, install gcc/clang/llvm etc., clang 11.0.0-2
- Clone the libbpf-boostrap repository
- Replace e.g. libbpf-boostrap/examples/c/kprobe.bpf.c with your example:
#include "vmlinux.h" #include <bpf/bpf_helpers.h> char LICENSE[] SEC("license") = "Dual BSD/GPL"; SEC("kprobe/vfs_read") int BPF_KPROBE(vfs_read_entry) { bpf_printk("hello world\n"); return 0; }
- Compile:
make -j kprobe
- I can't see the section:
$ readelf -SW .output/kprobe.bpf.o There are 13 section headers, starting at offset 0x430: Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 [ 1] .text PROGBITS 0000000000000000 000040 000000 00 AX 0 0 4 [ 2] kprobe/vfs_read PROGBITS 0000000000000000 000040 000030 00 AX 0 0 8 [ 3] license PROGBITS 0000000000000000 000070 00000d 00 WA 0 0 1 [ 4] .rodata PROGBITS 0000000000000000 00007d 00000e 00 A 0 0 1 [ 5] .BTF PROGBITS 0000000000000000 00008b 0001cc 00 0 0 1 [ 6] .BTF.ext PROGBITS 0000000000000000 000257 000060 00 0 0 1 [ 7] .symtab SYMTAB 0000000000000000 0002b8 000090 18 12 4 8 [ 8] .relkprobe/vfs_read REL 0000000000000000 000348 000010 10 7 2 8 [ 9] .rel.BTF REL 0000000000000000 000358 000020 10 7 5 8 [10] .rel.BTF.ext REL 0000000000000000 000378 000030 10 7 6 8 [11] .llvm_addrsig LOOS+0xfff4c03 0000000000000000 0003a8 000003 00 E 0 0 1 [12] .strtab STRTAB 0000000000000000 0003ab 000085 00 0 0 1
from bpftool.
Thanks for your reply.
I make a clear machine and do the same steps as you, and it works!
I compare the environment (including clang version, libbpf...) with my previous test, I find that the difference is libbpf version.
My previous test that returns errors use libbpf 0.4 version while the new test uses the latest version. When I update the libbpf from 0.4 to latest, the .rodata.str1.1 section disappears and the previous test also works.
But I am curious why the old libbpf version generates the .rodata.str1.1 section
from bpftool.
Great, thanks for testing! I want to investigate more on this but didn't have time this week, and will be off for the next ten days or so.
Regarding your findings: I wonder if we're talking of the same thing. Was it on kprobe.bpf.o
that you observe the .rodata.str1.1
section? I'm asking because libbpf is not involved in compiling from C into this file. It's only involved later, when parsing this ELF file to extract the eBPF bytecode and load it into the kernel. So the libbpf version should not have any influence on what sections are present in the ELF file - only on whether it can work with them when trying to parse and load. I didn't have time to check, but from the error you get, failed to find skeleton map
, I wonder if this might come from the skeleton generated by bpftool rather than from the eBPF program itself. I'll need to dig into a it a bit more.
from bpftool.
FYI, see libbpf/libbpf#274 .
from bpftool.
Thanks @chenhengqi! If I understand correctly, the issue should not happen now with recent clang and libbpf, which matches the observations here.
from bpftool.
Related Issues (20)
- `mount_bpffs_for_pin()`: if passing a directory, mount bpffs on this dir, not on parent dir HOT 22
- Print error and exit instead of diplaying an empty map for unsupported map types
- Fix weird indent in documentation HOT 1
- streamline bpftool net dump HOT 1
- "make install" for man pages stops. HOT 1
- Wrong callq address displayed HOT 5
- failed to open BPF object file: Operation not supported (Android Build via xmake) HOT 12
- Make error formatting consistent in libbpf and bpftool
- Skeletons: Improve support for 32-bit architectures
- Skeletons: Support cross-compiling towards architectures with different endianness HOT 1
- Add line annotations for control flow graph
- Zsh completion for bpftool
- can't mount BPF file system to pin the object HOT 2
- bpftool v6.7.0 load xdp program on Ubuntu 16.04 kernel 4.15.0-99-generic HOT 23
- Problem with Compilation of bpftool HOT 4
- Improve info for some link types in `bpftool link list`
- Update bpftool-cgroup documentation w.r.t. attach types HOT 1
- Fix LLVM detection in kernel repository HOT 1
- Support probing for kfuncs availability HOT 7
- “Fallthrough”: Replace comment by dedicated attribute HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bpftool.