All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	"Yonghong Song" <yhs@fb.com>, "Jiri Olsa" <jolsa@kernel.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andriin@fb.com>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	"Martin KaFai Lau" <kafai@fb.com>,
	"Song Liu" <songliubraving@fb.com>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"KP Singh" <kpsingh@chromium.org>,
	"Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Yauheni Kaliuta" <ykaliuta@redhat.com>,
	"Srikar Dronamraju" <srikar@linux.vnet.ibm.com>,
	"Paul Mackerras" <paulus@samba.org>
Subject: Re: [PATCH bpf-next] selftests/bpf: Fix test_attach_probe for powerpc uprobes
Date: Thu, 4 Mar 2021 16:55:28 +0100	[thread overview]
Message-ID: <YEEC8EiOiBaFhqxF@krava> (raw)
In-Reply-To: <87blbzsq3g.fsf@mpe.ellerman.id.au>

On Thu, Mar 04, 2021 at 11:46:27AM +1100, Michael Ellerman wrote:
> "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> writes:
> > On 2021/03/02 11:35AM, Jiri Olsa wrote:
> >> On Mon, Mar 01, 2021 at 02:58:53PM -0800, Yonghong Song wrote:
> >> > 
> >> > 
> >> > On 3/1/21 11:04 AM, Jiri Olsa wrote:
> >> > > When testing uprobes we the test gets GEP (Global Entry Point)
> >> > > address from kallsyms, but then the function is called locally
> >> > > so the uprobe is not triggered.
> >> > > 
> >> > > Fixing this by adjusting the address to LEP (Local Entry Point)
> >> > > for powerpc arch.
> >> > > 
> >> > > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> >> > > ---
> >> > >   .../selftests/bpf/prog_tests/attach_probe.c    | 18 +++++++++++++++++-
> >> > >   1 file changed, 17 insertions(+), 1 deletion(-)
> >> > > 
> >> > > diff --git a/tools/testing/selftests/bpf/prog_tests/attach_probe.c b/tools/testing/selftests/bpf/prog_tests/attach_probe.c
> >> > > index a0ee87c8e1ea..c3cfb48d3ed0 100644
> >> > > --- a/tools/testing/selftests/bpf/prog_tests/attach_probe.c
> >> > > +++ b/tools/testing/selftests/bpf/prog_tests/attach_probe.c
> >> > > @@ -2,6 +2,22 @@
> >> > >   #include <test_progs.h>
> >> > >   #include "test_attach_probe.skel.h"
> >> > > +#if defined(__powerpc64__)
> >
> > This needs to be specific to ELF v2 ABI, so you'll need to check 
> > _CALL_ELF. See commit d5c2e2c17ae1d6 ("perf probe ppc64le: Prefer symbol 
> > table lookup over DWARF") for an example.
> >
> >> > > +/*
> >> > > + * We get the GEP (Global Entry Point) address from kallsyms,
> >> > > + * but then the function is called locally, so we need to adjust
> >> > > + * the address to get LEP (Local Entry Point).
> >> > 
> >> > Any documentation in the kernel about this behavior? This will
> >> > help to validate the change without trying with powerpc64 qemu...
> >
> > I don't think we have documented this in the kernel anywhere, but this 
> > is specific to the ELF v2 ABI and is described there:
> > - 2.3.2.1.  Function Prologue: 
> >   http://cdn.openpowerfoundation.org/wp-content/uploads/resources/leabi/content/dbdoclet.50655240___RefHeading___Toc377640597.html
> > - 3.4.1.  Symbol Values:
> >    http://cdn.openpowerfoundation.org/wp-content/uploads/resources/leabi/content/dbdoclet.50655241_95185.html
> 
> There's a comment in ppc_function_entry(), but I don't think we have any
> actual "documentation".
> 
> static inline unsigned long ppc_function_entry(void *func)
> {
> #ifdef PPC64_ELF_ABI_v2
> 	u32 *insn = func;
> 
> 	/*
> 	 * A PPC64 ABIv2 function may have a local and a global entry
> 	 * point. We need to use the local entry point when patching
> 	 * functions, so identify and step over the global entry point
> 	 * sequence.

hm, so I need to do the instructions check below as well

> 	 *
> 	 * The global entry point sequence is always of the form:
> 	 *
> 	 * addis r2,r12,XXXX
> 	 * addi  r2,r2,XXXX
> 	 *
> 	 * A linker optimisation may convert the addis to lis:
> 	 *
> 	 * lis   r2,XXXX
> 	 * addi  r2,r2,XXXX
> 	 */
> 	if ((((*insn & OP_RT_RA_MASK) == ADDIS_R2_R12) ||
> 	     ((*insn & OP_RT_RA_MASK) == LIS_R2)) &&
> 	    ((*(insn+1) & OP_RT_RA_MASK) == ADDI_R2_R2))

is this check/instructions specific to kernel code?

In the test prog I see following instructions:

Dump of assembler code for function get_base_addr:
   0x0000000010034cb0 <+0>:     lis     r2,4256
   0x0000000010034cb4 <+4>:     addi    r2,r2,31488
   ...

but first instruction does not match the check in kernel code above:

	1.insn value:	0x3c4010a0
	2.insn value:	0x38427b00

the used defines are:
	#define OP_RT_RA_MASK   0xffff0000UL
	#define LIS_R2          0x3c020000UL
	#define ADDIS_R2_R12    0x3c4c0000UL
	#define ADDI_R2_R2      0x38420000UL


maybe we could skip the check, and run the test twice: first on
kallsym address and if the uprobe is not hit we will run it again
on address + 8

thanks,
jirka

> 		return (unsigned long)(insn + 2);
> 	else
> 		return (unsigned long)func;
> 
> 
> cheers
> 


  reply	other threads:[~2021-03-04 15:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-01 19:04 [PATCH bpf-next] selftests/bpf: Fix test_attach_probe for powerpc uprobes Jiri Olsa
2021-03-01 22:58 ` Yonghong Song
2021-03-02 10:35   ` Jiri Olsa
2021-03-03  6:40     ` Naveen N. Rao
2021-03-03 22:49       ` Jiri Olsa
2021-03-04  0:46       ` Michael Ellerman
2021-03-04 15:55         ` Jiri Olsa [this message]
2021-03-04  1:34           ` Naveen N. Rao
2021-03-05 13:38             ` Jiri Olsa
2021-03-02  0:34 ` Andrii Nakryiko
2021-03-02 11:14   ` Jiri Olsa
2021-03-02 17:19     ` Yonghong Song
2021-03-03  6:42       ` Naveen N. Rao
2021-03-02 18:31     ` Andrii Nakryiko
2021-03-02 18:58       ` Jiri Olsa

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YEEC8EiOiBaFhqxF@krava \
    --to=jolsa@redhat.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=mpe@ellerman.id.au \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=paulus@samba.org \
    --cc=songliubraving@fb.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=toke@redhat.com \
    --cc=yhs@fb.com \
    --cc=ykaliuta@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.