Hello everyone, I've been recently learning about BTF with a keen interest in using it as a fallback source of debug information. On the face of it, Linux kernels these days have a lot of introspection information. BTF provides information about types. kallsyms provides information about symbol locations. ORC allows us to reliably unwind stack traces. So together, these could enable a debugger (either postmortem, or live) to do a lot without needing to read the (very large) DWARF debuginfo files. For example, we could format backtraces with function names, we could pretty-print global variables and data structures, etc. This is nice given that depending on your distro, it might be tough to get debuginfo, and it is quite large to download or install. As I've worked toward this goal, I discovered that while the BTF_KIND_VAR exists [1], the BTF included in the core kernel only has declarations for percpu variables. This makes BTF much less useful for this (admittedly odd) use case. Without a way to bind a name found in kallsyms to its type, we can't interpret global variables. It looks like the restriction for percpu-only variables is baked into the pahole BTF encoder [2]. [1]: https://www.kernel.org/doc/html/latest/bpf/btf.html#btf-kind-var [2]: https://github.com/acmel/dwarves/blob/master/btf_encoder.c I wonder what the BPF / BTF community's thoughts are on including more of these global variable declarations? Perhaps behind a CONFIG_DEBUG_INFO_BTF_ALL, like how kallsyms does it? I'm aware that each declaration costs at least 16 bytes of BTF records, plus the strings and any necessary type data. The string cost could be mitigated by allowing "name_off" to refer to the kallsyms offset for variable or function declaration. But the additional records could cost around 1MiB for common distribution configurations. I know this isn't the designed use case for BTF, but I think it's very exciting. Thanks for your attention! Stephen
