From: Aditya Bodkhe <adityab1@linux.ibm.com>
To: Christophe Leroy <christophe.leroy@csgroup.eu>,
linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
maddy@linux.ibm.com, mpe@ellerman.id.au, npiggin@gmail.com,
rostedt@goodmis.org, mhiramat@kernel.org, mark.rutland@arm.com,
Aditya Bodkhe <aditya.b1@linux.ibm.com>
Subject: Re: [PATCH 1/2] powerpc/ftrace: support CONFIG_FUNCTION_GRAPH_RETVAL
Date: Fri, 13 Jun 2025 13:20:17 +0530 [thread overview]
Message-ID: <1e79fee0-2845-498f-bd16-4589edf19df7@linux.ibm.com> (raw)
In-Reply-To: <840249c5-2602-4178-a408-f7d502111f79@csgroup.eu>
On 03/06/25 2:22 pm, Christophe Leroy wrote:
>
>
> Le 28/05/2025 à 15:48, Aditya Bodkhe a écrit :
>> [Vous ne recevez pas souvent de courriers de adityab1@linux.ibm.com.
>> Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> From: Aditya Bodkhe <aditya.b1@linux.ibm.com>
>>
>> commit a1be9ccc57f0 ("function_graph: Support recording and printing the
>> return value of function") introduced support for function graph return
>> value tracing.
>>
>> Additionally, commit a3ed4157b7d8 ("fgraph: Replace fgraph_ret_regs with
>> ftrace_regs") further refactored and optimized the implementation,
>> making `struct fgraph_ret_regs` unnecessary.
>>
>> This patch enables the above modifications for powerpc64, ensuring that
>> function graph return value tracing is available on this architecture.
>
> Why only powerpc64 ?
>
> I see nothing specific to powerpc64 in your patch, will it work on
> powerpc32 too ?
>
That's a oversight on my part . This patch necessary changes for
powerpc32 bit and tested this feature to be working as expected on the same.
>>
>> After this patch, v6.14+ kernel can also be built with FPROBE on powerpc
>> but there are a few other build and runtime dependencies for FPROBE to
>> work properly. The next patch addresses them.
>>
>> Signed-off-by: Aditya Bodkhe <aditya.b1@linux.ibm.com>
>> ---
>> arch/powerpc/Kconfig | 1 +
>> arch/powerpc/include/asm/ftrace.h | 15 +++++++++
>> arch/powerpc/kernel/trace/ftrace_entry.S | 41 ++++++++++++++----------
>> 3 files changed, 40 insertions(+), 17 deletions(-)
>>
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index c3e0cc83f120..9163521bc4b9 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -250,6 +250,7 @@ config PPC
>> select HAVE_FUNCTION_ARG_ACCESS_API
>> select HAVE_FUNCTION_DESCRIPTORS if PPC64_ELF_ABI_V1
>> select HAVE_FUNCTION_ERROR_INJECTION
>> + select HAVE_FUNCTION_GRAPH_FREGS
>> select HAVE_FUNCTION_GRAPH_TRACER
>> select HAVE_FUNCTION_TRACER if !COMPILE_TEST &&
>> (PPC64 || (PPC32 && CC_IS_GCC))
>> select HAVE_GCC_PLUGINS if GCC_VERSION >=
>> 50200 # plugin support on gcc <= 5.1 is buggy on PPC
>> diff --git a/arch/powerpc/include/asm/ftrace.h
>> b/arch/powerpc/include/asm/ftrace.h
>> index 82da7c7a1d12..6ffc9c9cf4e3 100644
>> --- a/arch/powerpc/include/asm/ftrace.h
>> +++ b/arch/powerpc/include/asm/ftrace.h
>> @@ -50,6 +50,21 @@ static __always_inline struct pt_regs
>> *arch_ftrace_get_regs(struct ftrace_regs *
>> asm volatile("mfmsr %0" : "=r" ((_regs)->msr)); \
>> } while (0)
>>
>> +#undef ftrace_regs_get_return_value
>> +static __always_inline unsigned long
>> +ftrace_regs_get_return_value(const struct ftrace_regs *fregs)
>> +{
>> + return arch_ftrace_regs(fregs)->regs.gpr[3];
>> +}
>> +#define ftrace_regs_get_return_value ftrace_regs_get_return_value
>> +
>> +#undef ftrace_regs_get_frame_pointer
>> +static __always_inline unsigned long
>> +ftrace_regs_get_frame_pointer(const struct ftrace_regs *fregs)
>> +{
>> + return arch_ftrace_regs(fregs)->regs.gpr[1];
>> +}
>> +
> Why unset and redefine ftrace_regs_get_return_value() and
> ftrace_regs_get_frame_pointer() ? Please explain why the default ones
> can't be used on powerpc.
>
Because for powerpc currently for ftrace_regs_get_return_value() this
function regs_return_value() is getting called and it's implementation
returns -regs.gpr[3] if is_syscall_success() returns false . This was
causing fails in ftrace selftests .
Also for ftrace_regs_get_frame_pointer() current implementation was
always returning 0 hence we had to change that too .
>> static __always_inline void
>> ftrace_regs_set_instruction_pointer(struct ftrace_regs *fregs,
>> unsigned long ip)
>> diff --git a/arch/powerpc/kernel/trace/ftrace_entry.S
>> b/arch/powerpc/kernel/trace/ftrace_entry.S
>> index 3565c67fc638..eafbfb7584ed 100644
>> --- a/arch/powerpc/kernel/trace/ftrace_entry.S
>> +++ b/arch/powerpc/kernel/trace/ftrace_entry.S
>> @@ -409,23 +409,30 @@ EXPORT_SYMBOL(_mcount)
>> _GLOBAL(return_to_handler)
>> /* need to save return values */
>> #ifdef CONFIG_PPC64
>> - std r4, -32(r1)
>> - std r3, -24(r1)
>> + stdu r1, -SWITCH_FRAME_SIZE(r1)
>> + std r4, GPR4(r1)
>> + std r3, GPR3(r1)
>> + /* Save previous stack pointer (r1) */
>> + addi r3, r1, SWITCH_FRAME_SIZE
>> + std r3, GPR1(r1)
>> /* save TOC */
>> - std r2, -16(r1)
>> - std r31, -8(r1)
>> + std r2, 24(r1)
>> + std r31, 32(r1)
>> mr r31, r1
>> - stdu r1, -112(r1)
>> -
>> + /* pass ftrace_regs/pt_regs to ftrace_return_to_handler */
>> + addi r3, r1, STACK_INT_FRAME_REGS
>
> Some of the changes seems to only be renaming and should be done in a
> cleanup/preparatory patch in order to only focus on real necessary
> changes in this patch.
>
Now the way we are setting up the frame we cannot have negative offsets
, hence we used offsets which are defined already.
>> /*
>> * We might be called from a module.
>> * Switch to our TOC to run inside the core kernel.
>> */
>> LOAD_PACA_TOC()
>> #else
>> - stwu r1, -16(r1)
>> - stw r3, 8(r1)
>> - stw r4, 12(r1)
>> + stwu r1, -SWITCH_FRAME_SIZE(r1)
> Why do we need such a big frame size just to save two registers ?
>
This Frame size is needed because we need pt_regs as part of frame , are
you saying instead of SWITCH_FRAME_SIZE for 32 bit architecture we
should just setup a frame with size of pt_regs because ftrace_regs size
is same as pt_regs on ppc
>> + stw r4, GPR4(r1)
>> + stw r3, GPR3(r1)
>> + addi r3, r1, SWITCH_FRAME_SIZE
>> + stw r3, GPR1(r1)
> > + addi r3, r1, STACK_INT_FRAME_REGS
>
> Why is this needed ?
>
The function ftrace_return_to_handler takes pointer to pt_regs as
arguement so we are setting that up in stack and passing that pointer.
>> #endif
>>
>> bl ftrace_return_to_handler
>> @@ -435,15 +442,15 @@ _GLOBAL(return_to_handler)
>> mtlr r3
>>
>> #ifdef CONFIG_PPC64
>> - ld r1, 0(r1)
>> - ld r4, -32(r1)
>> - ld r3, -24(r1)
>> - ld r2, -16(r1)
>> - ld r31, -8(r1)
>> + ld r4, GPR4(r1)
>> + ld r3, GPR3(r1)
>> + ld r2, 24(r1)
>> + ld r31, 32(r1)
>> + ld r1, 0(r1)
>> #else
>> - lwz r3, 8(r1)
>> - lwz r4, 12(r1)
>> - addi r1, r1, 16
>> + lwz r3, GPR3(r1)
>> + lwz r4, GPR4(r1)
>> + addi r1, r1, SWITCH_FRAME_SIZE
>> #endif
>>
>> /* Jump back to real return address */
>> --
>> 2.43.5
>>
>
next prev parent reply other threads:[~2025-06-13 7:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-28 13:48 [PATCH 1/2] powerpc/ftrace: support CONFIG_FUNCTION_GRAPH_RETVAL Aditya Bodkhe
2025-05-28 13:48 ` [PATCH 2/2] powerpc/fprobe: fix updated fprobe for function-graph tracer Aditya Bodkhe
2025-06-09 7:47 ` Masami Hiramatsu
2025-06-02 12:36 ` [PATCH 1/2] powerpc/ftrace: support CONFIG_FUNCTION_GRAPH_RETVAL Hari Bathini
2025-06-03 8:52 ` Christophe Leroy
2025-06-13 7:50 ` Aditya Bodkhe [this message]
-- strict thread matches above, loose matches on Subject: below --
2025-07-07 7:18 Aditya Bodkhe
2025-07-07 7:50 ` Aditya Bodkhe
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=1e79fee0-2845-498f-bd16-4589edf19df7@linux.ibm.com \
--to=adityab1@linux.ibm.com \
--cc=aditya.b1@linux.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=rostedt@goodmis.org \
/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.