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. Are you worried about ulibc-like environment?