On Fri, 4 Feb 2022, Andrii Nakryiko wrote: > On Mon, Jan 31, 2022 at 8:13 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > > > kprobe attach is name-based, using lookups of kallsyms to translate > > a function name to an address. Currently uprobe attach is done > > via an offset value as described in [1]. Extend uprobe opts > > for attach to include a function name which can then be converted > > into a uprobe-friendly offset. The calcualation is done in > > several steps: > > > > 1. First, determine the symbol address using libelf; this gives us > > the offset as reported by objdump; then, in the case of local > > functions > > 2. If the function is a shared library function - and the binary > > provided is a shared library - no further work is required; > > the address found is the required address > > 3. If the function is a shared library function in a program > > (as opposed to a shared library), the Procedure Linking Table > > (PLT) table address is found (it is indexed via the dynamic > > symbol table index). This allows us to instrument a call > > to a shared library function locally in the calling binary, > > reducing overhead versus having a breakpoint in global lib. > > 4. Finally, if the function is local, subtract the base address > > associated with the object, retrieved from ELF program headers. > > > > The resultant value is then added to the func_offset value passed > > in to specify the uprobe attach address. So specifying a func_offset > > of 0 along with a function name "printf" will attach to printf entry. > > > > The modes of operation supported are then > > > > 1. to attach to a local function in a binary; function "foo1" in > > "/usr/bin/foo" > > 2. to attach to a shared library function in a binary; > > function "malloc" in "/usr/bin/foo" > > 3. to attach to a shared library function in a shared library - > > function "malloc" in libc. > > > > [1] https://www.kernel.org/doc/html/latest/trace/uprobetracer.html > > > > Signed-off-by: Alan Maguire <alan.maguire@xxxxxxxxxx> > > --- > > This looks great and very clean. I left a few nits, but otherwise it > looks ready (still need to go through the rest of the patches) > > > tools/lib/bpf/libbpf.c | 250 +++++++++++++++++++++++++++++++++++++++++++++++++ > > tools/lib/bpf/libbpf.h | 10 +- > > 2 files changed, 259 insertions(+), 1 deletion(-) > > > <snip> > if both the symbol name and requested function name have @ in them, > what should be the comparison rule? Shouldn't it be an exact match > including '@@' and part after it? > In this case, we might want to support matching on malloc@GLIBC and malloc@GLIBC_2.3.4; in other words letting the caller decide how specific they want to be makes sense I think. So the caller dictates the matching length via the argument they provide - with the proviso that if it's just a function name without a "@LIBRARY" suffix it must match fully. The problem with the version numbers associated with functions is they're the versions from the mapfiles, so the same library version has malloc@GLIBC_2.2.5, epoll_ctl@GLIBC_2.3.2 etc. Thanks for the review! I'm working on incorporating all of these changes into v4 now. Alan
