Johnny young <johnny96.young@xxxxxxxxx> writes:
> Hello BPF
>
> I understand that CONFIG_DEBUG_INFO_BTF=y will generate .BTF and
> .BTF_xx sections in the kernel image which are much smaller than
> those DWARF sections. But I also try to understand how BTF can impact
> bpftrace and the existing debug tools:
>
> 1) If the kernel is built with CONFIG_DEBUG_INFO_BTF=y, can
> bpftrace relies on BTF only without kernel_devel ?
>
> 2) Can the existing kernel debugging tools like crash(1) or
> kgdb(1) take advantage of BTF ?
Hi Johnny,
I can't answer all your questions but I can chime in regarding
debuggers. BTF could provide information to both of these debuggers, but
currently neither of them know how to use it. There's a few reasons and
challenges.
1. Kernel and module BTF today only includes the type information
necessary to describe all functions, and percpu variables. Most
debuggers would also like to know the types of global variables. I've
got a patch series [1] which allows pahole (which generates the
kernel & module BTF) to output information for global variable
declarations as well.
2. Assuming you had the BTF, you'd also need a symbol table. The kernel
has kallsyms, which is an internal symbol table, and most debuggers
today don't know how to read that - instead, they rely on the symbol
table from the ELF debuginfo file. I frequently work with a debugger
library called drgn [2], and I've got a branch out for review [3]
which enables drgn to read the kallsyms. In order to do that,
debuggers need to be able to *find* the kallsyms table, so I added
information to the vmcoreinfo note in the commits 5fd8fea935a1
("vmcoreinfo: include kallsyms symbols") and f09bddbd8661
("vmcoreinfo: add kallsyms_num_syms symbol").
3. Assuming you have symbol table access and the BTF is complete enough
for you to use it for real debugging, then your debugger still needs
to have logic to *find* the BTF and parse it (probably with libbpf).
I've got a branch for drgn [4] which implements BTF parsing on top of
the kallsyms parsing logic. With those things together, you get a
debugger which relies on nothing except data it finds inside the
kernel, and it works well enough.
So the short answer is - no, currently there is no debugger (that I know
of) which can leverage BTF. But it's in the works for drgn, and once we
get there with drgn, I'd hope to see that developers for other debuggers
might see the power of it and consider implementing it.
[1]: https://lore.kernel.org/bpf/20220826184911.168442-1-stephen.s.brennan@xxxxxxxxxx/
[2]: https://drgn.readthedocs.io/
[3]: https://github.com/osandov/drgn/pull/177
[4]: https://github.com/brenns10/drgn/tree/kallsyms_plus_btf
>
> 3) If the kernel is built with CONFIG_DEBUG_INFO_BTF=y, are the
> symbolic info and types info in the debug-info section replaced with
> BTF formatted info?
No, BTF is generated _in addition to_ the existing type information. BTF
doesn't store "symbolic info" i.e. symbol table data, so it couldn't
replace that data. It only stores type information, so hypothetically it
could be used instead of DWARF .debug_types data, but in practice that
doesn't happen.
Stephen
>
> 4) Given the current upstream development effort for BTF, can we run
> bpftrace without LLVM now ? and can we run bpftrace without the help
> of kernel header files (kernel-devel) ?
>
> 5) Has bpf CO-RE become reality now?
>
> Thank you!
> Johnny
