On 03.04.21 17:50, Andrii Nakryiko wrote:
On Fri, Apr 2, 2021 at 3:47 PM Felix Maurer <felix@xxxxxxxxxxxxxxx> wrote:Hello, I am working on a tracing tool for which I need know the address of some kernel data structures. The tool should be CO-RE and I am using libbpf (through the libbpf-rs Rust bindings, but this is not the issue I assume). However, I am having trouble to use ksyms with libbpf. To get the address of the data structure (in my case skbuff_fclone_cache), I use an extern ksym declaration in my BPF code like this: extern struct kmem_cache *skbuff_fclone_cache __ksym;Due to skbuff_fclone_cache being a static variable, typed __ksym (where you specify expected type and thus BPF verifier will expect BTF ID and will allow reading it directly from your BPF program) won't work. If you need to just have an address of the symbol, you can use untyped __ksym, which will use /proc/kallsyms: extern const void skbuff_fclone_cache __ksym; If you need to further read any data (e.g., follow the pointer and read struct kmem_cache's fields), you can use BPF_CORE_READ() macro.
Thank you very much for the explanation. The declaration like this works fine and solved my issues.
This also means that the whole chain works as expected, no bugs here :)
Now, I am not really sure where the root cause of the issue can be found. Should the ksym be present in the BTF information (i.e., the issue comes from building the kernel) or is the BPF object file broken (i.e., an issue with clang) or is the identification of the ksym wrong (i.e., the issue is in the libbpf loading code). Or something completely different? Does anyone have a hint on what goes wrong here?As Yonghong already replied, pahole doesn't generate BTF type information for static variables right now, so it's expected. [...]
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
