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?

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.

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.

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