From: Andrii Nakryiko <firstname.lastname@example.org>
To: Alan Maguire <email@example.com>
Cc: Alexei Starovoitov <firstname.lastname@example.org>,
Daniel Borkmann <email@example.com>,
Andrii Nakryiko <firstname.lastname@example.org>, Martin Lau <email@example.com>,
Song Liu <firstname.lastname@example.org>, Yonghong Song <email@example.com>,
john fastabend <firstname.lastname@example.org>,
KP Singh <email@example.com>, Jiri Olsa <firstname.lastname@example.org>,
Yucong Sun <email@example.com>,
Networking <firstname.lastname@example.org>, bpf <email@example.com>
Subject: Re: [RFC bpf-next 0/4] libbpf: userspace attach by name
Date: Wed, 12 Jan 2022 09:04:30 -0800 [thread overview]
Message-ID: <CAEf4BzYRLxzVHw00DUphqqdv2m_AU7Mu=S0JF0PZYN40hBvHgA@mail.gmail.com> (raw)
On Wed, Jan 12, 2022 at 8:19 AM Alan Maguire <firstname.lastname@example.org> wrote:
> This patch series is a rough attempt to support attach by name for
> uprobes and USDT (Userland Static Defined Tracing) probes.
> 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.
> One restriction applies: uprobe attach supports system-wide probing
> by specifying "-1" for the pid. That functionality is not supported,
> since we need a running process to determine the base address to
> subtract to get the uprobe-friendly offset. There may be a way
> to do this without a running process, so any suggestions would
> be greatly appreciated.
> There are probably a bunch of subtleties missing here; the aim
> is to see if this is useful and if so hopefully we can refine
> it to deal with more complex cases. I tried to handle one case
> that came to mind - weak library symbols - but there are probably
> other issues when determining which address to use I haven't
> thought of.
> Alan Maguire (4):
> libbpf: support function name-based attach for uprobes
> libbpf: support usdt provider/probe name-based attach for uprobes
> selftests/bpf: add tests for u[ret]probe attach by name
> selftests/bpf: add test for USDT uprobe attach by name
I've been working on USDT support last year. It's considerably more
code than in this RFC, but it handles not just finding a location of
USDT probe(s), but also fetching its arguments based on argument
location specification and more usability focused BPF-side APIs to
work with USDTs.
I don't remember how up to date it is, but the last "open source"
version of it can be found at . I currently have the latest
debugged and tested version internally in the process of being
integrated into our profiling solution here at Meta. So far it seems
to be working fine and covers our production use cases well.
The plan is to open source it as a separate companion library to
libbpf some time in the next few months. Hopefully that would work for
you. Once it is available, I hope we can also utilize it to convert
some more BCC-based tools (that rely on USDT) to libbpf ().
> tools/lib/bpf/libbpf.c | 244 +++++++++++++++++++++
> tools/lib/bpf/libbpf.h | 17 +-
> tools/testing/selftests/bpf/Makefile | 34 +++
> .../selftests/bpf/prog_tests/attach_probe.c | 74 ++++++-
> .../selftests/bpf/progs/test_attach_probe.c | 24 ++
> 5 files changed, 391 insertions(+), 2 deletions(-)
next prev parent reply other threads:[~2022-01-12 17:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-12 16:18 [RFC bpf-next 0/4] libbpf: userspace attach by name Alan Maguire
2022-01-12 16:18 ` [RFC bpf-next 1/4] libbpf: support function name-based attach for uprobes Alan Maguire
2022-01-12 16:18 ` [RFC bpf-next 2/4] libbpf: support usdt provider/probe " Alan Maguire
2022-01-12 16:18 ` [RFC bpf-next 3/4] selftests/bpf: add tests for u[ret]probe attach by name Alan Maguire
2022-01-12 16:18 ` [RFC bpf-next 4/4] selftests/bpf: add test for USDT uprobe " Alan Maguire
2022-01-12 17:04 ` Andrii Nakryiko [this message]
2022-01-13 10:29 ` [RFC bpf-next 0/4] libbpf: userspace " Alan Maguire
2022-01-14 20:48 ` Andrii Nakryiko
2022-01-19 14:03 ` Alan Maguire
2022-01-19 18:49 ` Andrii Nakryiko
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).