Building header files into the kernel

Posted Mar 23, 2019 0:36 UTC (Sat) by adirat (subscriber, #86623)
In reply to: Building header files into the kernel by dezgeg
Parent article: Building header files into the kernel

All this is really bleeding edge development and I'm not one of the few experts, but I can point you to this presentation from the last LPC microconf which talks about #defines in BTF a little. The consensus among the experts seems to be that, at least for the time beeing, BTF can't replace kernel headers, while the Android devs need a solution yesterday, so here we are at this kernel-headers patch instead of waiting and investing more time to do research :)

http://vger.kernel.org/lpc-bpf2018.html#session-2

Building header files into the kernel

Posted Mar 24, 2019 1:32 UTC (Sun) by _joel_ (subscriber, #112763) [Link] (6 responses)

We already know about BTF and this was already discussed in the patch postings. Please read the threads in v4 of the posting. BTF is insufficient for this usecase.

Building header files into the kernel

Posted Mar 25, 2019 13:34 UTC (Mon) by adirat (subscriber, #86623) [Link] (5 responses)

I've read the v4 discussion and honestly it only strengthens my assessment: Google engineers are really rushing this patchset instead of exploring alternative solutions. It seems like you just want something ready to use now with minimum effort. Please take a timeout, go back to the drawing board and come back in 1 year with a BTF extension or something similar based on ORC/DWARF.

I get it that some people are afraid of hard work or telling their managers/marketing they need more time, but you guys are burning a lot of credibility here by saying some very silly things, for example let me quote from the v4 thread exchange [1]:

> Think of the headers as encoding this information and more and the C
> compiler as a magical decoder ring. :-) I totally get the desire for a
> metadata format a little less messy than C code, but as a practical
> matter, a rich C-compilation pipeline already exists, and the
> debuginfo you're proposing doesn't, (...)

The C compiler as magical decoder ring? Really? It never crossed your mind to actually develop that debug info which you need? :) What's next, including GCC/LLVM itself in the kernel as a module because eBPF also needs them to compile its "restricted-C"? Then BCC and python/lua? Again: wake up, do the proper work and stop pushing bad solutions.

[1] https://lkml.org/lkml/2019/3/11/1352

Building header files into the kernel

Posted Mar 26, 2019 23:46 UTC (Tue) by jsmith45 (guest, #125263) [Link]

Sure, with the right flags you can get macro definitions in the DWARF data, and extract them. But apparently compiling the kernel even with the normal debug flags can cause compilation to be quite a bit slower, and generate an enormous amount of data, and this would need even more data.

And parsing out the correct set of macros from that debug info may not be entirely trivial. (Some macros may have multiple values in different spots in the kernel.) Even if those issues were solved, and we had the macro data to combine with BTF it is not equivalent to headers. One thing that does not get captured is inline functions defined in the headers. I've no idea if those ever get used in BPF programs, but I could certainly imagine that at least some of them may work (e.g. if they are just abstracting over a struct access). And those are impossible to extract from any form of debugging information.

Building header files into the kernel

Posted Sep 14, 2021 1:13 UTC (Tue) by nickodell (subscriber, #125165) [Link] (3 responses)

> I get it that some people are afraid of hard work or telling their managers/marketing they need more time, but you guys are burning a lot of credibility here by saying some very silly things, for example let me quote from the v4 thread exchange [1]:
>[...]
>The C compiler as magical decoder ring? Really? It never crossed your mind to actually develop that debug info which you need? :)

I think you're underestimating the work involved in getting a C compiler to both emit and understand the new debug info. E.g. the preprocessor must know how to use macros from the debug info for substitution. The typechecker must know how to use function prototypes to check that a function is being called with the appropriate types. The compiler must know how to load structure definitions so that it knows what offset to access data from within a struct.

The only current data format that carries all that information is a C header file. Could you develop a new format which does not carry extraneous information like comments? Sure. But you'd be introducing an unknown number of bugs. The payoff for doing that is at most 4MB of freed memory. Approaches which load the tar file on demand, or that allow it to be paged in and out, seem much more promising.

Building header files into the kernel

Posted Sep 15, 2021 12:42 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

Well... both CTF and BTF carry all that information, and weigh in at a few megabytes for a full monster enterprise kernel (complete with, in the CTF case, all types used by in-tree modules as well). They're certainly both a lot smaller than the header files that were the source for a lot of their content would be.

Building header files into the kernel

Posted Sep 15, 2021 13:30 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link] (1 responses)

What's the difference between CTF and BTF and do we need both? I couldn't find a succinct summary.

Building header files into the kernel

Posted Sep 15, 2021 16:49 UTC (Wed) by nix (subscriber, #2304) [Link]

They are distinct things these days and can both be present at the same time without conflict. BTF is created from DWARF by pahole (in dwarves) and has no plans to work for anything but the kernel (not that this matters for this use case): CTF is generated by trunk GCC and linked and dedupped by recent-enough GNU ld, but you cannot yet generate header files from CTF (not because it's impossible, but just because I haven't written the code to do that yet: I will do it soon, and add it as an objdump option).

They are both derived from the same ancestor (Solaris CTF) but have a significant number of differences by now, mostly reflecting their kernel-only versus userspace focuses (e.g. CTF supports symbol -> type lookup using the ELF symtab, which obviously makes little sense for BTF; BTF has a whole elaborate pile of relocation machinery for CO-RE, tightly tied to LLVM at present, that isn't in CTF).