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. [...] > > 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. [...]
