This patch series is a refinement of the RFC patchset [1], focusing
on support for attach by name for uprobes and uretprobes. Still
marked RFC as there are unresolved questions.
Currently attach for such probes is done by determining the offset
manually, so the aim is to try and mimic the simplicity of kprobe
attach, making use of uprobe opts to specify a name string.
uprobe attach is done by specifying a binary path, a pid (where
0 means "this process" and -1 means "all processes") and an
offset. Here a 'func_name' option is added to 'struct uprobe_opts'
and that name is searched for in symbol tables. If the binary
is a program, relative offset calcuation must be done to the
symbol address as described in [2].
Having a name allows us to support auto-attach via SEC()
specification, for example
SEC("uprobe/usr/lib64/libc.so.6/malloc")
Unresolved questions:
- the current scheme uses
u[ret]probe[/]/path/2/binary/function[+offset]
...as SEC() format for auto-attach, for example
SEC("uprobe/usr/lib64/libc.so.6/malloc")
It would be cleaner to delimit binary and function with ':'
as is done by bcc. One simple way to achieve that would be
to support section string pre-processing, where instances of
':' are replaced by a '/'; this would get us to supporting
a similar probe specification as bcc without the backward
compatibility headaches. I can't think of any valid
cases where SEC() definitions have a ':' that we would
replace with '/' in error, but I might be missing something.
- the current scheme doesn't support a raw offset address, since
it felt un-portable to encourage that, but can add this support
if needed.
- The auto-attach behaviour is to attach to all processes.
It would be good to have a way to specify the attach process
target. A few possibilities that would be compatible with
BPF skeleton support are to use the open opts (feels kind of
wrong conceptually since it's an attach-time attribute) or
to support opts with attach pid field in "struct bpf_prog_skeleton".
Latter would even allow a skeleton to attach to multiple
different processes with prog-level granularity (perhaps a union
of the various attach opts or similar?). There may be other
ways to achieve this.
Changes since RFC [1]:
- focused on uprobe entry/return, omitting USDT attach (Andrii)
- use ELF program headers in calculating relative offsets, as this
works for the case where we do not specify a process. The
previous approach relied on /proc/pid/maps so would not work
for the "all processes" case (where pid is -1).
- add support for auto-attach (patch 2)
- fix selftests to use a real library function. I didn't notice
selftests override the usleep(3) definition, so as a result of
this, the libc function wasn't being called, so usleep() should
not be used to test shared library attach. Also switch to
using libc path as the binary argument for these cases, as
specifying a shared library function name for a program is
not supported. Tests now instrument malloc/free.
- added selftest that verifies auto-attach.
[1] https://lore.kernel.org/bpf/1642004329-23514-1-git-send-email-alan.maguire@xxxxxxxxxx/
[2] https://www.kernel.org/doc/html/latest/trace/uprobetracer.html
Alan Maguire (3):
libbpf: support function name-based attach for uprobes
libbpf: add auto-attach for uprobes based on section name
selftests/bpf: add tests for u[ret]probe attach by name
tools/lib/bpf/libbpf.c | 259 ++++++++++++++++++++-
tools/lib/bpf/libbpf.h | 10 +-
.../selftests/bpf/prog_tests/attach_probe.c | 114 +++++++--
.../selftests/bpf/progs/test_attach_probe.c | 33 +++
4 files changed, 396 insertions(+), 20 deletions(-)
--
1.8.3.1
