On Sun, 2022-04-03 at 21:46 -0700, Andrii Nakryiko wrote: > On Sun, Apr 3, 2022 at 6:14 PM Andrii Nakryiko > <andrii.nakryiko@xxxxxxxxx> wrote: > > > > On Wed, Mar 30, 2022 at 8:27 AM Alan Maguire > > <alan.maguire@xxxxxxxxxx> wrote: > > > > > > Now that u[ret]probes can use name-based specification, it makes > > > sense to add support for auto-attach based on SEC() definition. > > > The format proposed is > > > > > > > > > SEC("u[ret]probe/binary:[raw_offset|[function_name[+offset]]") > > > > > > For example, to trace malloc() in libc: > > > > > > SEC("uprobe/libc.so.6:malloc") > > > > > > ...or to trace function foo2 in /usr/bin/foo: > > > > > > SEC("uprobe//usr/bin/foo:foo2") > > > > > > Auto-attach is done for all tasks (pid -1). prog can be an > > > absolute > > > path or simply a program/library name; in the latter case, we use > > > PATH/LD_LIBRARY_PATH to resolve the full path, falling back to > > > standard locations (/usr/bin:/usr/sbin or /usr/lib64:/usr/lib) if > > > the file is not found via environment-variable specified > > > locations. > > > > > > Signed-off-by: Alan Maguire <alan.maguire@xxxxxxxxxx> > > > --- > > > tools/lib/bpf/libbpf.c | 74 > > > ++++++++++++++++++++++++++++++++++++++++++++++++-- > > > 1 file changed, 72 insertions(+), 2 deletions(-) > > > > > > > [...] > > > > > +static int attach_uprobe(const struct bpf_program *prog, long > > > cookie, struct bpf_link **link) > > > +{ > > > + DECLARE_LIBBPF_OPTS(bpf_uprobe_opts, opts); > > > + char *func, *probe_name, *func_end; > > > + char *func_name, binary_path[512]; > > > + unsigned long long raw_offset; > > > + size_t offset = 0; > > > + int n; > > > + > > > + *link = NULL; > > > + > > > + opts.retprobe = str_has_pfx(prog->sec_name, > > > "uretprobe/"); > > > + if (opts.retprobe) > > > + probe_name = prog->sec_name + > > > sizeof("uretprobe/") - 1; > > > + else > > > + probe_name = prog->sec_name + sizeof("uprobe/") - > > > 1; > > > > I think this will mishandle SEC("uretprobe"), let's fix this in a > > follow up (and see a note about uretprobe selftests) > > So I actually fixed it up a little bit to avoid test failure on s390x > arch. But now it's a different problem, complaining about not being > able to resolve libc.so.6. CC'ing Ilya, but I was wondering if it's > better to use more generic "libc.so" instead of "libc.so.6"? Have you > tried that? I believe it's a Debian-specific issue (our s390x CI image is Debian). libc is still called libc.so.6, but it's located in /lib/s390x-linux-gnu. This must also be an issue on Intel and other architectures. I'll send a patch.