Add ability to trace all functions in eBPF kernel drivers

[abeltrano]

Describe the feature you'd like supported

Performance investigation can benefit from accurate measurement of time spent in a particular function. This is especially important for hot execution paths called from eBPF extensions.
 
dtrace can be used to trace most user and kernel functions using Function Boundary Tracing (fbt). Fbt instrumentation uses unwind information from the pdata image section to get information about function prologue and epilogues; this is sometime unavailable for leaf functions not calling any imported API since they may not have unwind information.

The eBPF kernel drivers should be modified such that tracing tools such as dtrace can be used to trace all functions.

Proposed solution

The /allpdata linker flag forces inclusion of all functions in the pdata section, thus enabling FBT tracing of any function.

Additional context

No response

[dthaler]

If dtrace is later implemented on top of ebpf, would this cause a circular dependency?
Or how would it work? I.e., what happens if you try to trace the dtrace implementation with dtrace today?

[abeltrano]

If dtrace is later implemented on top of ebpf,

When I briefly discussed this with @Alan-Jowett, he mentioned that implementing dtrace with ebpf was proposed in the past. Seems like an interesting idea. I believe he mentioned the primary reasoning against this approach was concern about having an "interpreter" in the kernel, though don't know if that's still true today. Do you know if there is serious interest in this possibility today, or was your question more out of curiosity?

would this cause a circular dependency? Or how would it work? I.e., what happens if you try to trace the dtrace implementation with dtrace today?

Good question, I don't know, but I believe I saw something in the dtrace docs that excludes tracing its own impl. I'll look into this more deeply to understand this better and report back.

[shankarseal]

The /allpdata linker flag generates stack unwinding information that can be consumed by dtrace among other tools. This is not specific to dtrace.
The point about cyclic dependency will be considered if/when dtrace is implemented using eBPF.

[Alan-Jowett]

Here is more information about pdata for reference:
https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#the-pdata-section