[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241104094431.GY29862@gate.crashing.org>
Date: Mon, 4 Nov 2024 03:44:31 -0600
From: Segher Boessenkool <segher@...nel.crashing.org>
To: Hari Bathini <hbathini@...ux.ibm.com>
Cc: Shuah Khan <shuah@...nel.org>, linux-kselftest@...r.kernel.org,
Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Michael Ellerman <mpe@...erman.id.au>,
Madhavan Srinivasan <maddy@...ux.ibm.com>,
"Naveen N. Rao" <naveen@...nel.org>,
lkml <linux-kernel@...r.kernel.org>,
linux-trace-kernel@...r.kernel.org,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH] selftests/ftrace: update kprobe syntax error test for ppc64le
Hi!
On Mon, Nov 04, 2024 at 02:51:57PM +0530, Hari Bathini wrote:
> On 02/11/24 2:29 am, Segher Boessenkool wrote:
> >On Sat, Nov 02, 2024 at 12:49:25AM +0530, Hari Bathini wrote:
> >>For ppc64le, depending on the kernel configuration used, offset 16
> >>from function start address can also be considered function entry.
> >>Update the test case to accommodate such configurations.
> >
> >(This is true for all ELfv2, not just LE. For the kernel that is about
> >the same).
> >
> >The LEP and GEP can differ by zero, one, two, four, eight, or sixteen
> >insns (where an insn is four bytes). Four insns is common, yes, but
> >maybe you can support all? See the function symbol's st_other field
> >to see what the offset is:
> >0, 1: zero insns, zero bytes
> >N = 2..6: 1 << (N-2) insns, i.e. 1<<N bytes
> >7: reserved
> >
> >(This is the top 3 bits of st_other, the other bits have other meanings).
> >
> >Four insns is common, yes, but by no means the only possibility.
>
> Hi Segher,
>
> Querying for function arguments is supported on kprobes only at function
> entry. This is a negative test case where the offset is intentionally
> set beyond function entry while querying for function arguments.
> I guess, simply setting the offset to 20 (vfs_read is anyway
> going to be beyond 5 instructions) instead of 8 for powerpc would
> make all platforms and ABI variants happy?
I have no idea. What is this "offset" anyway?
This is just the ELFv2 ABI. No platform can make up its own thing at
all (well, none decided to be gratuitously incompatible, so far). And
there are no "ABI variants"!
You're just making assumptions here that are based on nothing else but
observations of what is done most of the time. That might work for a
while -- maybe a long while even! -- but it can easily break down.
Segher
Powered by blists - more mailing lists