Re: [RFC PATCH bpf-next 00/12] bpf: Introduce static-defined tracing probe for BPF

From: Xu Kuohai

Date: Mon Jun 29 2026 - 21:19:54 EST

On 6/29/2026 9:53 PM, Leon Hwang wrote:
On 2026/6/29 19:32, Xu Kuohai wrote:
On 6/29/2026 6:55 PM, Leon Hwang wrote:
On 29/6/26 15:51, Xu Kuohai wrote:

With the elimination, the callsite of 'subprog' has been eliminated.

However, as you mentioned above, the argument preparation insns are
kept.


I see, the CALL insntruction is removed, not patched to NOP.

So the call site is either a call to subprog, or totally removed. The
fentry
tracing only works when the CALL instruction and the subprog are not
eliminated.
This is exactly what SDT tries to solve.

So, why not add a macro for the stub following the subprog+fentry idea?

#define DEFINE_TRACING_STUB(__stub, ...)     \
static __noinline void __stub(...)        \
{                        \
    ...                    \
}

DEFINE_TRACING_STUB(my_trace, int, len, int, ret);

SEC("xdp")
int xdp_prog(struct xdp_md *ctx)
{
    ...
    my_trace(len, ret);
    ...
}

Then, add a libbpf API bpf_program__remove_stub(prog, my_stub) to drop
the stub by the way like my demo.


Since the stub prog is dropped in libbpf, where is the fentry prog
attached?


No. By default, the stub prog won't be dropped by libbpf. The
bpf_program__remove_stub() API is provided so that users can
intentionally remove the stub prog.

Maybe bpf_program__remove_subprog() would be a better name for the API,
because it is to remove a subprog.


So it is more of a user-space workaround than a formal solution. And even
for this workaround, there is no need to add a new libbpf API to remove the
stub. You can simply build two versions of bpf prog, one with subprog and
one without. When you need to trace fentry, load the first one; otherwise,
load the second one.

What SDT resolves is dynamic tracing after the prog is loaded, the hacking
before loading does not apply.

Thanks,
Leon