[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzaX70Ze2mdLuQvw8kNqCt7fQAOkO=Akm=T9Pjxf4eDpLA@mail.gmail.com>
Date: Fri, 14 Jan 2022 12:48:46 -0800
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Alan Maguire <alan.maguire@...cle.com>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>, Martin Lau <kafai@...com>,
Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
john fastabend <john.fastabend@...il.com>,
KP Singh <kpsingh@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
Yucong Sun <sunyucong@...il.com>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [RFC bpf-next 0/4] libbpf: userspace attach by name
On Thu, Jan 13, 2022 at 2:30 AM Alan Maguire <alan.maguire@...cle.com> wrote:
>
> On Wed, 12 Jan 2022, Andrii Nakryiko wrote:
>
> > On Wed, Jan 12, 2022 at 8:19 AM Alan Maguire <alan.maguire@...cle.com> 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
> > >
> >
> > Hey Alan,
> >
> > 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 [0]. 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.
> >
>
> This looks great Andrii! I really like the argument access work, and the
> global tracing part is solved too by using the ELF segment info instead
> of the process maps to get the relative offset, with (I think?) use of
> BPF cookies to disambiguate between different user attachments.
BPF cookies are mandatory for when attaching to a shared library *and*
NOT specifying PID. This is actually the mode that BCC doesn't seem to
support. In all other cases BPF cookie shouldn't be mandatory.
>
> The one piece that seems to be missing from my perspective - and this may
> be in more recent versions - is uprobe function attachment by name. Most of
> the work is already done in libusdt so it's reasonably doable I think - at a
> minimum it would require an equivalent to the find_elf_func_offset()
> function in my patch 1. Now the name of the library libusdt suggests its
> focus is on USDT of course, but I think having userspace function attach
> by name too would be great. Is that part of your plans for this work?
True, uprobes don't supprot attaching by function name, which is quite
annoying. It's certainly not a focus for libusdt (or whatever it will
end up being called when open-sources). But if it's not much code and
complexity we should probably just add that to libbpf directly for
uprobes.
>
> Thanks!
>
> Alan
Powered by blists - more mailing lists