Hi Masami, Sorry for late reply as I was traveling.
On Wed, Mar 13, 2019 at 10:18:43AM +0900, Masami Hiramatsu wrote:
On Mon, 11 Mar 2019 18:38:49 -0700 Joel Fernandes joelaf@google.com wrote:
On Mon, Mar 11, 2019 at 6:28 PM Steven Rostedt rostedt@goodmis.org wrote:
On Mon, 11 Mar 2019 20:39:12 -0400 Joel Fernandes joel@joelfernandes.org wrote:
I think even though the kernel-headers can't have information about all data structures, they do already contain a lot of data structure definitions we need already. And anything needed can/should arguably be moved to include/ if they are really needed for kernel extension by something "external" to the kernel such as kernel modules or eBPF, right?
That's not my worry. I would like to be able to easily walk data structures from within the kernel, without having to do a lot of work in userspace to get that information. The kprobe_events could then be passed type casts or such to access data fields of arguments to functions and such.
Ok.
In any case, such a solution such as what Steve suggested, still cannot do what we can with headers - such as build kernel modules on the fly using the C-compiler without any auto-generation of C code from any debug artifiacts. Think systemtap working with the module-backend without any need for linux-headers package on the file system. So such a solution would still be a bit orthogonal in scope to what this proposed solution can solve IMO.
With the information I would like to have, it would be trivial to read the data to create the header files needed for modules.
But there are macros and other #define things too. We lose all of them and can't recreate them from just DWARF (AFAIK). Including include/generated/autoconf.h which #defines the CONFIG options. For that we either need headers, or full kernel's sources with build artifacts.
What kind of macros would you concern?
I do see a use case for the debug info you are talking about as you mentioned for the kprobe_events argument list types, and I already thought about it. But it does not seem to work for all the use cases I am referring to here.
But the eBPF is based on kprobe-events. What kind of usage would you expected? (with macros??)
eBPF C programs are compiled with kernel headers. They can execute inline functions or refer to macros in the kernel headers. They are similar to kernel modules where you build a C program that then later is executed in kernel context. It goes through the whole compiler pipeline. This is slightly different usage from pure kprobe-events. Also eBPF kprobe programs need LINUX_VERSION_CODE (or similarly named) macro which it provides to the bpf(2) syscall when loading kprobe programs. This is because eBPF implementation in the kernel checks if the eBPF programs that use kprobes are being loaded against the right kernel.
thanks,
- Joel