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.
```
tracepoint:foo:bar,
tracepoint:baz:something
{
print("hi")
}
```
Thanks,
Daniel
