On Mon, Jan 06, 2025 at 10:32:15AM +0800, Yafang Shao wrote:
> On Mon, Jan 6, 2025 at 8:16 AM Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> wrote:
> >
> > On Sun, Jan 5, 2025 at 4:44 AM Yafang Shao <laoar.shao@xxxxxxxxx> wrote:
> > >
> > > Dynamic tracepoints can be created using debugfs. For example:
> > >
> > > echo 'p:myprobe kernel_clone args' >> /sys/kernel/debug/tracing/kprobe_events
> > >
> > > This command creates a new tracepoint under debugfs:
> > >
> > > $ ls /sys/kernel/debug/tracing/events/kprobes/myprobe/
> > > enable filter format hist id trigger
> > >
> > > Although this dynamic tracepoint appears as a tracepoint, it is internally
> > > implemented as a kprobe. However, it must be attached as a tracepoint to
> > > function correctly in certain contexts.
> >
> > Nack.
> > There are multiple mechanisms to create kprobe/tp via text interfaces.
> > We're not going to mix them with the programmatic libbpf api.
>
> It appears that bpftrace still lacks support for adding a kprobe/tp
> and then attaching to it directly. Is that correct?
> What do you think about introducing this mechanism into bpftrace? With
> such a feature, we could easily attach to inlined kernel functions
> using bpftrace.
so with the 'echo .. > kprobe_events' you create kprobe which will be
exported through tracefs together with other tracepoints and bpftrace
sees it as another tracepoint.. but it's a kprobe :-\
how about we add support for kprobe section like SEC("kprobe/SUBSYSTEM/PROBE"),
so in your case above it'd be SEC("kprobe/kprobes/myprobe")
then attach_kprobe would parse that out and use new new probe_attach_mode
for bpf_program__attach_kprobe_opts to attach it correctly
cc-ing Viktor
jirka
