On Wed, Jul 12, 2023 at 9:56 PM Daniel Xu <dxu@xxxxxxxxx> wrote:
>
> On Wed, Jul 12, 2023 at 09:13:04PM -0700, Andrii Nakryiko wrote:
> > On Wed, Jul 12, 2023 at 8:05 AM Alexei Starovoitov
> > <alexei.starovoitov@xxxxxxxxx> wrote:
> > >
> > > On Tue, Jul 11, 2023 at 10:42 PM Andrii Nakryiko
> > > <andrii.nakryiko@xxxxxxxxx> wrote:
> > > >
> > > > On Tue, Jul 11, 2023 at 6:05 PM Jackie Liu <liu.yun@xxxxxxxxx> wrote:
> > > > >
> > > > > From: Jackie Liu <liuyun01@xxxxxxxxxx>
> > > > >
> > > > > Now multi kprobe uses glob_match for function matching, it's not enough,
> > > > > and sometimes we need more powerful regular expressions to support fuzzy
> > > > > matching, and now provides a use_regex in bpf_kprobe_multi_opts to support
> > > > > POSIX regular expressions.
> > > > >
> > > > > This is useful, similar to `funccount.py -r '^vfs.*'` in BCC, and can also
> > > > > be implemented with libbpf.
> > > > >
> > > > > Signed-off-by: Jackie Liu <liuyun01@xxxxxxxxxx>
> > > > > ---
> > > > > tools/lib/bpf/libbpf.c | 52 ++++++++++++++++++++++++++++++++++++++----
> > > > > tools/lib/bpf/libbpf.h | 4 +++-
> > > > > 2 files changed, 51 insertions(+), 5 deletions(-)
> > > > >
> > > >
> > > > Let's hold off on adding regex support assumptions into libbpf API.
> > > > Globs are pretty flexible already for most cases, and for some more
> > > > advanced use cases users can provide an exact list of function names
> > > > through opts argument.
> > > >
> > > > We can revisit this decision down the road, but right now it seems
> > > > premature to sign up for such relatively heavy-weight API dependency.
> > >
> > > regexec() is part of glibc and we cannot link it statically,
> > > so no change in libbpf.a/so size.
> >
> > right, I wasn't worried about the code size increase of libbpf itself
> >
> > > Are you worried about ulibc-like environment?
> >
> > This is one part. musl, uclibc, and other alternative implementations
> > of glibc: do they support same functionality with all the same options
> > and syntax. I'd feel more comfortable if we understood well all the
> > implications of relying on this regex API: which glibc versions
> > support it, same for musl. Are there any extra library dependencies
> > that we might need to add (like -lm for some math functions). I'm not
> > very familiar also with what regex flavor is implemented by POSIX
> > regex, is it the commonly-expected Perl-compatible one, or something
> > else?
> >
> > Also, we should have a good story on how this regex syntax is
> > supported in SEC() definitions for both kprobe.multi and uprobe.multi.
> >
> > Stuff like this.
> >
> > But also, looking at bpftrace, I don't think it supports regex-based
> > probe matching (e.g., I tried 'kprobe:.*sys_bpf' and it matched
> > nothing; maybe there is some other syntax, but my Google-fu failed
> > me). So assuming I didn't miss anything obvious with bpftrace, the
> > fact that it's been around for so long with so many users and lack of
> > regex doesn't seem to be the problem,
>
> bpftrace only supports wildcard (`*`) operator like in globs. One thing
> that might help bpftrace get away with that is being able to specify multiple
> attachpoints for a single probe. Eg.
Right, and you can do the same with libbpf. Call
bpf_program__attach_kprobe_multi() multiple times with different globs
and/or define multiple SEC("kprobe.multi/xxx") entry functions that
just call into a common logic-handling subprog.
I find, in practice, that regexes are often completely unnecessary for
selecting subsets of functions, if one has globs already.
>
> ```
> tracepoint:foo:bar,
> tracepoint:baz:something
> {
> print("hi")
> }
> ```
>
> Thanks,
> Daniel
