[PATCH] riscv: ftrace: Fix the logic issue in DYNAMIC_FTRACE selection

[PATCH] riscv: ftrace: Fix the logic issue in DYNAMIC_FTRACE selection

[ChenMiao]

From: chenmiao <chenmiao.ku@gmail.com>

When I was reading the source code of ftrace, I learned that
ftrace has two types: static and dynamic. Initially, I planned
to prioritize reading the static source code, so I disabled
the enable dynamic option in RISCV.

[*]   Kernel Function Tracer
[ ]   Kernel Function Graph Tracer
[ ]   enable/disable function tracing dynamically (NEW)

However, when I tried to compile it, the build failed.

./include/linux/ftrace.h:190:16: error: implicit declaration of
function ‘arch_ftrace_get_regs’; did you mean ‘arch_ftrace_regs’?
[-Wimplicit-function-declaration]
  190 |         return arch_ftrace_get_regs(fregs);
      |                ^~~~~~~~~~~~~~~~~~~~
      |                arch_ftrace_regs

After comparing it with the ARM64 architecture, I found that
ARM64 automatically enables DYNAMIC_FTRACE by default once
FUNCTION_TRACER is turned on, and this cannot be set to "no".
Therefore, I believe the optional DYNAMIC_FTRACE setting in
RISC-V has a logic flaw—if FUNCTION_TRACER is enabled,
DYNAMIC_FTRACE should also be enabled, and vice versa. Moreover,
it's clear that RISC-V lacks the necessary support to successfully
compile the kernel when DYNAMIC_FTRACE is disabled.

[*]   Kernel Function Tracer
[ ]   Kernel Function Graph Tracer
-*-   enable/disable function tracing dynamically

Signed-off-by: chenmiao <chenmiao.ku@gmail.com>
---
 arch/riscv/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 36061f473..f7fc8b460 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -97,6 +97,7 @@ config RISCV
 	select CLONE_BACKWARDS
 	select COMMON_CLK
 	select CPU_PM if CPU_IDLE || HIBERNATION || SUSPEND
+	select DYNAMIC_FTRACE if FUNCTION_TRACER
 	select EDAC_SUPPORT
 	select FRAME_POINTER if PERF_EVENTS || (FUNCTION_TRACER && !DYNAMIC_FTRACE)
 	select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY if DYNAMIC_FTRACE
-- 
2.45.2

[PATCH] riscv: ftrace: Fix the logic issue in DYNAMIC_FTRACE selection

[ChenMiao]

From: chenmiao <chenmiao.ku@gmail.com>

When I was reading the source code of ftrace, I learned that
ftrace has two types: static and dynamic. Initially, I planned
to prioritize reading the static source code, so I disabled
the enable dynamic option in RISCV.

[*]   Kernel Function Tracer
[ ]   Kernel Function Graph Tracer
[ ]   enable/disable function tracing dynamically (NEW)

However, when I tried to compile it, the build failed.

./include/linux/ftrace.h:190:16: error: implicit declaration of
function ‘arch_ftrace_get_regs’; did you mean ‘arch_ftrace_regs’?
[-Wimplicit-function-declaration]
  190 |         return arch_ftrace_get_regs(fregs);
      |                ^~~~~~~~~~~~~~~~~~~~
      |                arch_ftrace_regs

After comparing it with the ARM64 architecture, I found that
ARM64 automatically enables DYNAMIC_FTRACE by default once
FUNCTION_TRACER is turned on, and this cannot be set to "no".
Therefore, I believe the optional DYNAMIC_FTRACE setting in
RISC-V has a logic flaw—if FUNCTION_TRACER is enabled,
DYNAMIC_FTRACE should also be enabled, and vice versa. Moreover,
it's clear that RISC-V lacks the necessary support to successfully
compile the kernel when DYNAMIC_FTRACE is disabled.

[*]   Kernel Function Tracer
[ ]   Kernel Function Graph Tracer
-*-   enable/disable function tracing dynamically

Signed-off-by: chenmiao <chenmiao.ku@gmail.com>
---
 arch/riscv/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 36061f473..f7fc8b460 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -97,6 +97,7 @@ config RISCV
 	select CLONE_BACKWARDS
 	select COMMON_CLK
 	select CPU_PM if CPU_IDLE || HIBERNATION || SUSPEND
+	select DYNAMIC_FTRACE if FUNCTION_TRACER
 	select EDAC_SUPPORT
 	select FRAME_POINTER if PERF_EVENTS || (FUNCTION_TRACER && !DYNAMIC_FTRACE)
 	select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY if DYNAMIC_FTRACE
-- 
2.45.2

Re: [PATCH] riscv: ftrace: Fix the logic issue in DYNAMIC_FTRACE selection

[Alexandre Ghiti]

Hi ChenMiao,

On 7/3/25 10:45, ChenMiao wrote:
> From: chenmiao <chenmiao.ku@gmail.com>
>
> When I was reading the source code of ftrace, I learned that
> ftrace has two types: static and dynamic. Initially, I planned
> to prioritize reading the static source code, so I disabled
> the enable dynamic option in RISCV.
>
> [*]   Kernel Function Tracer
> [ ]   Kernel Function Graph Tracer
> [ ]   enable/disable function tracing dynamically (NEW)
>
> However, when I tried to compile it, the build failed.
>
> ./include/linux/ftrace.h:190:16: error: implicit declaration of
> function ‘arch_ftrace_get_regs’; did you mean ‘arch_ftrace_regs’?
> [-Wimplicit-function-declaration]
>    190 |         return arch_ftrace_get_regs(fregs);
>        |                ^~~~~~~~~~~~~~~~~~~~
>        |                arch_ftrace_regs
>
> After comparing it with the ARM64 architecture, I found that
> ARM64 automatically enables DYNAMIC_FTRACE by default once
> FUNCTION_TRACER is turned on, and this cannot be set to "no".
> Therefore, I believe the optional DYNAMIC_FTRACE setting in
> RISC-V has a logic flaw—if FUNCTION_TRACER is enabled,
> DYNAMIC_FTRACE should also be enabled, and vice versa. Moreover,
> it's clear that RISC-V lacks the necessary support to successfully
> compile the kernel when DYNAMIC_FTRACE is disabled.


We could support static ftrace, but I don't think we should, so I agree 
with this patch. In fact I had just prepared a patch for this here 
https://github.com/linux-riscv/linux/pull/556/commits/0481092a5bec3818658981c11f629e06e66382b3 
which is a bit more complete since I have removed some dead code.

Let's see what other people think about supporting static ftrace, I have 
added Steven in cc if he has an opinion.

Thanks,

Alex


>
> [*]   Kernel Function Tracer
> [ ]   Kernel Function Graph Tracer
> -*-   enable/disable function tracing dynamically
>
> Signed-off-by: chenmiao <chenmiao.ku@gmail.com>
> ---
>   arch/riscv/Kconfig | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index 36061f473..f7fc8b460 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -97,6 +97,7 @@ config RISCV
>   	select CLONE_BACKWARDS
>   	select COMMON_CLK
>   	select CPU_PM if CPU_IDLE || HIBERNATION || SUSPEND
> +	select DYNAMIC_FTRACE if FUNCTION_TRACER
>   	select EDAC_SUPPORT
>   	select FRAME_POINTER if PERF_EVENTS || (FUNCTION_TRACER && !DYNAMIC_FTRACE)
>   	select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY if DYNAMIC_FTRACE

Re: [PATCH] riscv: ftrace: Fix the logic issue in DYNAMIC_FTRACE selection

[Steven Rostedt]

On Thu, 3 Jul 2025 15:00:02 +0200
Alexandre Ghiti <alex@ghiti.fr> wrote:


> 
> We could support static ftrace, but I don't think we should, so I agree 
> with this patch. In fact I had just prepared a patch for this here 
> https://github.com/linux-riscv/linux/pull/556/commits/0481092a5bec3818658981c11f629e06e66382b3 
> which is a bit more complete since I have removed some dead code.
> 
> Let's see what other people think about supporting static ftrace, I have 
> added Steven in cc if he has an opinion.

Yes, please only support the dynamic ftrace. The static is there only
to help archs to get ftrace up and running. Once dynamic is supported,
static should not be used.

Hmm, maybe I should just remove the prompt for DYNAMIC_FTRACE.

That is, once it is supported by an architecture, it should be the only
thing used.

-- Steve

Re: [PATCH] riscv: ftrace: Fix the logic issue in DYNAMIC_FTRACE selection

[Alexandre Ghiti]

Hi Steve,

On 7/3/25 17:40, Steven Rostedt wrote:
> On Thu, 3 Jul 2025 15:00:02 +0200
> Alexandre Ghiti <alex@ghiti.fr> wrote:
>
>
>> We could support static ftrace, but I don't think we should, so I agree
>> with this patch. In fact I had just prepared a patch for this here
>> https://github.com/linux-riscv/linux/pull/556/commits/0481092a5bec3818658981c11f629e06e66382b3
>> which is a bit more complete since I have removed some dead code.
>>
>> Let's see what other people think about supporting static ftrace, I have
>> added Steven in cc if he has an opinion.
> Yes, please only support the dynamic ftrace. The static is there only
> to help archs to get ftrace up and running. Once dynamic is supported,
> static should not be used.
>
> Hmm, maybe I should just remove the prompt for DYNAMIC_FTRACE.
>
> That is, once it is supported by an architecture, it should be the only
> thing used.
>
> -- Steve


Thanks for your input.

@ChenMiao: can you come up with a v2 that, in addition, deletes the dead 
code and with a commit log that explains what Steven said? If not 
possible for you, let me know and I'll do it.

Thanks,

Alex

Re: [PATCH] riscv: ftrace: Fix the logic issue in DYNAMIC_FTRACE selection

[kernel test robot]

Hi ChenMiao,

kernel test robot noticed the following build warnings:

[auto build test WARNING on linus/master]
[also build test WARNING on v6.16-rc4 next-20250703]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/ChenMiao/riscv-ftrace-Fix-the-logic-issue-in-DYNAMIC_FTRACE-selection/20250703-165308
base:   linus/master
patch link:    https://lore.kernel.org/r/20250703084818.394491-1-chenmiao.ku%40gmail.com
patch subject: [PATCH] riscv: ftrace: Fix the logic issue in DYNAMIC_FTRACE selection
config: riscv-kismet-CONFIG_DYNAMIC_FTRACE-CONFIG_RISCV-0-0 (https://download.01.org/0day-ci/archive/20250704/202507041001.7eWJmB1g-lkp@intel.com/config)
reproduce: (https://download.01.org/0day-ci/archive/20250704/202507041001.7eWJmB1g-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202507041001.7eWJmB1g-lkp@intel.com/

kismet warnings: (new ones prefixed by >>)
>> kismet: WARNING: unmet direct dependencies detected for DYNAMIC_FTRACE when selected by RISCV
   

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [PATCH] riscv: ftrace: Fix the logic issue in DYNAMIC_FTRACE selection

[Alexandre Ghiti]

Hi Chen Miao,

On 7/4/25 04:06, Miao Chen wrote:
> Hello Alex,
>
> Should I wait for Steven to finish his work before starting mine? He 
> seems to be refactoring a lot of CONFIG logic, which might cause 
> conflicts.


I would say no, don't wait for Steven since his work won't land in 6.16, 
we need a fix to prevent build failures for this release.

Thanks,

Alex


>
> Thanks,
>
> Chen Miao
>
> Alexandre Ghiti <alex@ghiti.fr> 于2025年7月4日周五 00:06写道：
>
>     Hi Steve,
>
>     On 7/3/25 17:40, Steven Rostedt wrote:
>     > On Thu, 3 Jul 2025 15:00:02 +0200
>     > Alexandre Ghiti <alex@ghiti.fr> wrote:
>     >
>     >
>     >> We could support static ftrace, but I don't think we should, so
>     I agree
>     >> with this patch. In fact I had just prepared a patch for this here
>     >>
>     https://github.com/linux-riscv/linux/pull/556/commits/0481092a5bec3818658981c11f629e06e66382b3
>     >> which is a bit more complete since I have removed some dead code.
>     >>
>     >> Let's see what other people think about supporting static
>     ftrace, I have
>     >> added Steven in cc if he has an opinion.
>     > Yes, please only support the dynamic ftrace. The static is there
>     only
>     > to help archs to get ftrace up and running. Once dynamic is
>     supported,
>     > static should not be used.
>     >
>     > Hmm, maybe I should just remove the prompt for DYNAMIC_FTRACE.
>     >
>     > That is, once it is supported by an architecture, it should be
>     the only
>     > thing used.
>     >
>     > -- Steve
>
>
>     Thanks for your input.
>
>     @ChenMiao: can you come up with a v2 that, in addition, deletes
>     the dead
>     code and with a commit log that explains what Steven said? If not
>     possible for you, let me know and I'll do it.
>
>     Thanks,
>
>     Alex
>

Re: [PATCH] riscv: ftrace: Fix the logic issue in DYNAMIC_FTRACE selection

[Steven Rostedt]

On July 4, 2025 8:28:31 AM EDT, Alexandre Ghiti <alex@ghiti.fr> wrote:
>Hi Chen Miao,
>
>On 7/4/25 04:06, Miao Chen wrote:
>> Hello Alex,
>> 
>> Should I wait for Steven to finish his work before starting mine? He seems to be refactoring a lot of CONFIG logic, which might cause conflicts.
>
>
>I would say no, don't wait for Steven since his work won't land in 6.16, we need a fix to prevent build failures for this release.
>

Agreed,

-- Steve

>
>> 

Re: [PATCH] riscv: ftrace: Fix the logic issue in DYNAMIC_FTRACE selection

[Miao Chen]

Hi Alex,

Ok, I'll start my work right now.

Thanks,

Chen Miao


Alexandre Ghiti <alex@ghiti.fr> 于2025年7月4日周五 20:28写道：
>
> Hi Chen Miao,
>
> On 7/4/25 04:06, Miao Chen wrote:
> > Hello Alex,
> >
> > Should I wait for Steven to finish his work before starting mine? He
> > seems to be refactoring a lot of CONFIG logic, which might cause
> > conflicts.
>
>
> I would say no, don't wait for Steven since his work won't land in 6.16,
> we need a fix to prevent build failures for this release.
>
> Thanks,
>
> Alex
>
>
> >
> > Thanks,
> >
> > Chen Miao
> >
> > Alexandre Ghiti <alex@ghiti.fr> 于2025年7月4日周五 00:06写道：
> >
> >     Hi Steve,
> >
> >     On 7/3/25 17:40, Steven Rostedt wrote:
> >     > On Thu, 3 Jul 2025 15:00:02 +0200
> >     > Alexandre Ghiti <alex@ghiti.fr> wrote:
> >     >
> >     >
> >     >> We could support static ftrace, but I don't think we should, so
> >     I agree
> >     >> with this patch. In fact I had just prepared a patch for this here
> >     >>
> >     https://github.com/linux-riscv/linux/pull/556/commits/0481092a5bec3818658981c11f629e06e66382b3
> >     >> which is a bit more complete since I have removed some dead code.
> >     >>
> >     >> Let's see what other people think about supporting static
> >     ftrace, I have
> >     >> added Steven in cc if he has an opinion.
> >     > Yes, please only support the dynamic ftrace. The static is there
> >     only
> >     > to help archs to get ftrace up and running. Once dynamic is
> >     supported,
> >     > static should not be used.
> >     >
> >     > Hmm, maybe I should just remove the prompt for DYNAMIC_FTRACE.
> >     >
> >     > That is, once it is supported by an architecture, it should be
> >     the only
> >     > thing used.
> >     >
> >     > -- Steve
> >
> >
> >     Thanks for your input.
> >
> >     @ChenMiao: can you come up with a v2 that, in addition, deletes
> >     the dead
> >     code and with a commit log that explains what Steven said? If not
> >     possible for you, let me know and I'll do it.
> >
> >     Thanks,
> >
> >     Alex
> >

Re: [PATCH] riscv: ftrace: Fix the logic issue in DYNAMIC_FTRACE selection

[kernel test robot]

Hi ChenMiao,

kernel test robot noticed the following build errors:

[auto build test ERROR on linus/master]
[also build test ERROR on v6.16-rc4 next-20250704]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/ChenMiao/riscv-ftrace-Fix-the-logic-issue-in-DYNAMIC_FTRACE-selection/20250703-165308
base:   linus/master
patch link:    https://lore.kernel.org/r/20250703084818.394491-1-chenmiao.ku%40gmail.com
patch subject: [PATCH] riscv: ftrace: Fix the logic issue in DYNAMIC_FTRACE selection
config: riscv-randconfig-001-20250706 (https://download.01.org/0day-ci/archive/20250706/202507060946.JDTW8TlM-lkp@intel.com/config)
compiler: riscv64-linux-gcc (GCC) 11.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250706/202507060946.JDTW8TlM-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202507060946.JDTW8TlM-lkp@intel.com/

All errors (new ones prefixed by >>):

   arch/riscv/kernel/mcount-dyn.S: Assembler messages:
>> arch/riscv/kernel/mcount-dyn.S:85: Error: illegal operands `addi sp,sp,-FREGS_SIZE_ON_STACK'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:86: Error: illegal operands `sd t0,FREGS_EPC(sp)'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:87: Error: illegal operands `sd x1,FREGS_RA(sp)'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:91: Error: illegal operands `sd x6,FREGS_T1(sp)'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:100: Error: illegal operands `sd x10,FREGS_A0(sp)'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:101: Error: illegal operands `sd x11,FREGS_A1(sp)'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:102: Error: illegal operands `sd x12,FREGS_A2(sp)'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:103: Error: illegal operands `sd x13,FREGS_A3(sp)'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:104: Error: illegal operands `sd x14,FREGS_A4(sp)'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:105: Error: illegal operands `sd x15,FREGS_A5(sp)'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:106: Error: illegal operands `sd x16,FREGS_A6(sp)'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:107: Error: illegal operands `sd x17,FREGS_A7(sp)'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:109: Error: illegal operands `addi a0,a0,FREGS_SIZE_ON_STACK'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:110: Error: illegal operands `sd a0,FREGS_SP(sp)'
   arch/riscv/kernel/mcount-dyn.S:185:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:114: Error: illegal operands `ld t0,FREGS_EPC(sp)'
   arch/riscv/kernel/mcount-dyn.S:195:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:115: Error: illegal operands `ld x1,FREGS_RA(sp)'
   arch/riscv/kernel/mcount-dyn.S:195:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:119: Error: illegal operands `ld x6,FREGS_T1(sp)'
   arch/riscv/kernel/mcount-dyn.S:195:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:128: Error: illegal operands `ld x10,FREGS_A0(sp)'
   arch/riscv/kernel/mcount-dyn.S:195:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:129: Error: illegal operands `ld x11,FREGS_A1(sp)'
   arch/riscv/kernel/mcount-dyn.S:195:  Info: macro invoked from here
>> arch/riscv/kernel/mcount-dyn.S:130: Error: illegal operands `ld x12,FREGS_A2(sp)'
   arch/riscv/kernel/mcount-dyn.S:195:  Info: macro invoked from here
   arch/riscv/kernel/mcount-dyn.S:131: Error: illegal operands `ld x13,FREGS_A3(sp)'
   arch/riscv/kernel/mcount-dyn.S:195:  Info: macro invoked from here
   arch/riscv/kernel/mcount-dyn.S:132: Error: illegal operands `ld x14,FREGS_A4(sp)'
   arch/riscv/kernel/mcount-dyn.S:195:  Info: macro invoked from here
   arch/riscv/kernel/mcount-dyn.S:133: Error: illegal operands `ld x15,FREGS_A5(sp)'
   arch/riscv/kernel/mcount-dyn.S:195:  Info: macro invoked from here
   arch/riscv/kernel/mcount-dyn.S:134: Error: illegal operands `ld x16,FREGS_A6(sp)'
   arch/riscv/kernel/mcount-dyn.S:195:  Info: macro invoked from here
   arch/riscv/kernel/mcount-dyn.S:135: Error: illegal operands `ld x17,FREGS_A7(sp)'
   arch/riscv/kernel/mcount-dyn.S:195:  Info: macro invoked from here
   arch/riscv/kernel/mcount-dyn.S:137: Error: illegal operands `addi sp,sp,FREGS_SIZE_ON_STACK'
   arch/riscv/kernel/mcount-dyn.S:195:  Info: macro invoked from here

Kconfig warnings: (for reference only)
   WARNING: unmet direct dependencies detected for DYNAMIC_FTRACE
   Depends on [n]: FTRACE [=y] && FUNCTION_TRACER [=y] && HAVE_DYNAMIC_FTRACE [=n]
   Selected by [y]:
   - RISCV [=y] && FUNCTION_TRACER [=y]


vim +85 arch/riscv/kernel/mcount-dyn.S

afc76b8b8011218 Guo Ren        2020-12-17   27  
afc76b8b8011218 Guo Ren        2020-12-17   28  	.macro SAVE_ABI
afc76b8b8011218 Guo Ren        2020-12-17   29  	addi	sp, sp, -ABI_SIZE_ON_STACK
afc76b8b8011218 Guo Ren        2020-12-17   30  
afc76b8b8011218 Guo Ren        2020-12-17   31  	REG_S	a0, ABI_A0(sp)
afc76b8b8011218 Guo Ren        2020-12-17   32  	REG_S	a1, ABI_A1(sp)
afc76b8b8011218 Guo Ren        2020-12-17   33  	REG_S	a2, ABI_A2(sp)
afc76b8b8011218 Guo Ren        2020-12-17   34  	REG_S	a3, ABI_A3(sp)
afc76b8b8011218 Guo Ren        2020-12-17   35  	REG_S	a4, ABI_A4(sp)
afc76b8b8011218 Guo Ren        2020-12-17   36  	REG_S	a5, ABI_A5(sp)
afc76b8b8011218 Guo Ren        2020-12-17   37  	REG_S	a6, ABI_A6(sp)
afc76b8b8011218 Guo Ren        2020-12-17   38  	REG_S	a7, ABI_A7(sp)
6724a76cff85ee2 Guo Ren        2023-01-12   39  	REG_S	t0, ABI_T0(sp)
afc76b8b8011218 Guo Ren        2020-12-17   40  	REG_S	ra, ABI_RA(sp)
c15ac4fd60d5ffd Alan Kao       2018-02-13   41  	.endm
c15ac4fd60d5ffd Alan Kao       2018-02-13   42  
afc76b8b8011218 Guo Ren        2020-12-17   43  	.macro RESTORE_ABI
afc76b8b8011218 Guo Ren        2020-12-17   44  	REG_L	a0, ABI_A0(sp)
afc76b8b8011218 Guo Ren        2020-12-17   45  	REG_L	a1, ABI_A1(sp)
afc76b8b8011218 Guo Ren        2020-12-17   46  	REG_L	a2, ABI_A2(sp)
afc76b8b8011218 Guo Ren        2020-12-17   47  	REG_L	a3, ABI_A3(sp)
afc76b8b8011218 Guo Ren        2020-12-17   48  	REG_L	a4, ABI_A4(sp)
afc76b8b8011218 Guo Ren        2020-12-17   49  	REG_L	a5, ABI_A5(sp)
afc76b8b8011218 Guo Ren        2020-12-17   50  	REG_L	a6, ABI_A6(sp)
afc76b8b8011218 Guo Ren        2020-12-17   51  	REG_L	a7, ABI_A7(sp)
6724a76cff85ee2 Guo Ren        2023-01-12   52  	REG_L	t0, ABI_T0(sp)
afc76b8b8011218 Guo Ren        2020-12-17   53  	REG_L	ra, ABI_RA(sp)
afc76b8b8011218 Guo Ren        2020-12-17   54  
afc76b8b8011218 Guo Ren        2020-12-17   55  	addi	sp, sp, ABI_SIZE_ON_STACK
c15ac4fd60d5ffd Alan Kao       2018-02-13   56  	.endm
c15ac4fd60d5ffd Alan Kao       2018-02-13   57  
35e61e8827ee8ea Song Shuai     2023-11-30   58  /**
7caa9765465f60b Puranjay Mohan 2024-04-05   59  * SAVE_ABI_REGS - save regs against the ftrace_regs struct
35e61e8827ee8ea Song Shuai     2023-11-30   60  *
35e61e8827ee8ea Song Shuai     2023-11-30   61  * After the stack is established,
35e61e8827ee8ea Song Shuai     2023-11-30   62  *
35e61e8827ee8ea Song Shuai     2023-11-30   63  * 0(sp) stores the PC of the traced function which can be accessed
b2137c3b6d7a456 Andy Chiu      2025-04-08   64  * by &(fregs)->epc in tracing function.
35e61e8827ee8ea Song Shuai     2023-11-30   65  *
35e61e8827ee8ea Song Shuai     2023-11-30   66  * 8(sp) stores the function return address (i.e. parent IP) that
7caa9765465f60b Puranjay Mohan 2024-04-05   67  * can be accessed by &(fregs)->ra in tracing function.
35e61e8827ee8ea Song Shuai     2023-11-30   68  *
35e61e8827ee8ea Song Shuai     2023-11-30   69  * The other regs are saved at the respective localtion and accessed
7caa9765465f60b Puranjay Mohan 2024-04-05   70  * by the respective ftrace_regs member.
35e61e8827ee8ea Song Shuai     2023-11-30   71  *
35e61e8827ee8ea Song Shuai     2023-11-30   72  * Here is the layout of stack for your reference.
35e61e8827ee8ea Song Shuai     2023-11-30   73  *
35e61e8827ee8ea Song Shuai     2023-11-30   74  * PT_SIZE_ON_STACK  ->  +++++++++
35e61e8827ee8ea Song Shuai     2023-11-30   75  *                       + ..... +
35e61e8827ee8ea Song Shuai     2023-11-30   76  *                       + a0-a7 + --++++-> ftrace_caller saved
7caa9765465f60b Puranjay Mohan 2024-04-05   77  *                       + t1    + --++++-> direct tramp address
7caa9765465f60b Puranjay Mohan 2024-04-05   78  *                       + s0    + --+ // frame pointer
35e61e8827ee8ea Song Shuai     2023-11-30   79  *                       + sp    +   +
35e61e8827ee8ea Song Shuai     2023-11-30   80  *                       + ra    + --+ // parent IP
35e61e8827ee8ea Song Shuai     2023-11-30   81  *               sp  ->  + epc   + --+ // PC
35e61e8827ee8ea Song Shuai     2023-11-30   82  *                       +++++++++
35e61e8827ee8ea Song Shuai     2023-11-30   83  **/
7caa9765465f60b Puranjay Mohan 2024-04-05   84  	.macro SAVE_ABI_REGS
7caa9765465f60b Puranjay Mohan 2024-04-05  @85  	addi	sp, sp, -FREGS_SIZE_ON_STACK
7caa9765465f60b Puranjay Mohan 2024-04-05  @86  	REG_S	t0,  FREGS_EPC(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05  @87  	REG_S	x1,  FREGS_RA(sp)
35e61e8827ee8ea Song Shuai     2023-11-30   88  #ifdef HAVE_FUNCTION_GRAPH_FP_TEST
7caa9765465f60b Puranjay Mohan 2024-04-05   89  	REG_S	x8,  FREGS_S0(sp)
35e61e8827ee8ea Song Shuai     2023-11-30   90  #endif
7caa9765465f60b Puranjay Mohan 2024-04-05  @91  	REG_S	x6,  FREGS_T1(sp)
f8693f6dffcd186 Andy Chiu      2025-04-08   92  #ifdef CONFIG_CC_IS_CLANG
f8693f6dffcd186 Andy Chiu      2025-04-08   93  	REG_S	x7,  FREGS_T2(sp)
f8693f6dffcd186 Andy Chiu      2025-04-08   94  	REG_S	x28, FREGS_T3(sp)
f8693f6dffcd186 Andy Chiu      2025-04-08   95  	REG_S	x29, FREGS_T4(sp)
f8693f6dffcd186 Andy Chiu      2025-04-08   96  	REG_S	x30, FREGS_T5(sp)
f8693f6dffcd186 Andy Chiu      2025-04-08   97  	REG_S	x31, FREGS_T6(sp)
f8693f6dffcd186 Andy Chiu      2025-04-08   98  #endif
7caa9765465f60b Puranjay Mohan 2024-04-05   99  	// save the arguments
7caa9765465f60b Puranjay Mohan 2024-04-05 @100  	REG_S	x10, FREGS_A0(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @101  	REG_S	x11, FREGS_A1(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @102  	REG_S	x12, FREGS_A2(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @103  	REG_S	x13, FREGS_A3(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @104  	REG_S	x14, FREGS_A4(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @105  	REG_S	x15, FREGS_A5(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @106  	REG_S	x16, FREGS_A6(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @107  	REG_S	x17, FREGS_A7(sp)
b21cdb9523e5561 Andy Chiu      2025-04-08  108  	mv	a0, sp
b21cdb9523e5561 Andy Chiu      2025-04-08 @109  	addi	a0, a0, FREGS_SIZE_ON_STACK
b21cdb9523e5561 Andy Chiu      2025-04-08 @110  	REG_S	a0, FREGS_SP(sp)	// Put original SP on stack
bc1a4c3a8425568 Alan Kao       2018-02-13  111  	.endm
bc1a4c3a8425568 Alan Kao       2018-02-13  112  
b21cdb9523e5561 Andy Chiu      2025-04-08  113  	.macro RESTORE_ABI_REGS
7caa9765465f60b Puranjay Mohan 2024-04-05 @114  	REG_L	t0, FREGS_EPC(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @115  	REG_L	x1, FREGS_RA(sp)
35e61e8827ee8ea Song Shuai     2023-11-30  116  #ifdef HAVE_FUNCTION_GRAPH_FP_TEST
7caa9765465f60b Puranjay Mohan 2024-04-05  117  	REG_L	x8, FREGS_S0(sp)
35e61e8827ee8ea Song Shuai     2023-11-30  118  #endif
7caa9765465f60b Puranjay Mohan 2024-04-05 @119  	REG_L	x6,  FREGS_T1(sp)
f8693f6dffcd186 Andy Chiu      2025-04-08  120  #ifdef CONFIG_CC_IS_CLANG
f8693f6dffcd186 Andy Chiu      2025-04-08  121  	REG_L	x7,  FREGS_T2(sp)
f8693f6dffcd186 Andy Chiu      2025-04-08  122  	REG_L	x28, FREGS_T3(sp)
f8693f6dffcd186 Andy Chiu      2025-04-08  123  	REG_L	x29, FREGS_T4(sp)
f8693f6dffcd186 Andy Chiu      2025-04-08  124  	REG_L	x30, FREGS_T5(sp)
f8693f6dffcd186 Andy Chiu      2025-04-08  125  	REG_L	x31, FREGS_T6(sp)
f8693f6dffcd186 Andy Chiu      2025-04-08  126  #endif
7caa9765465f60b Puranjay Mohan 2024-04-05  127  	// restore the arguments
7caa9765465f60b Puranjay Mohan 2024-04-05 @128  	REG_L	x10, FREGS_A0(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @129  	REG_L	x11, FREGS_A1(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @130  	REG_L	x12, FREGS_A2(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @131  	REG_L	x13, FREGS_A3(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @132  	REG_L	x14, FREGS_A4(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @133  	REG_L	x15, FREGS_A5(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @134  	REG_L	x16, FREGS_A6(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05 @135  	REG_L	x17, FREGS_A7(sp)
7caa9765465f60b Puranjay Mohan 2024-04-05  136  
7caa9765465f60b Puranjay Mohan 2024-04-05  137  	addi	sp, sp, FREGS_SIZE_ON_STACK
afc76b8b8011218 Guo Ren        2020-12-17  138  	.endm
35e61e8827ee8ea Song Shuai     2023-11-30  139  
35e61e8827ee8ea Song Shuai     2023-11-30  140  	.macro PREPARE_ARGS
b2137c3b6d7a456 Andy Chiu      2025-04-08  141  	addi	a0, t0, -MCOUNT_JALR_SIZE	// ip (callsite's jalr insn)
b21cdb9523e5561 Andy Chiu      2025-04-08  142  #ifdef CONFIG_DYNAMIC_FTRACE_WITH_CALL_OPS
b21cdb9523e5561 Andy Chiu      2025-04-08  143  	mv 	a1, ra				// parent_ip
b21cdb9523e5561 Andy Chiu      2025-04-08  144  	REG_L   a2, -16(t0)			// op
b21cdb9523e5561 Andy Chiu      2025-04-08  145  	REG_L   ra, FTRACE_OPS_FUNC(a2)		// op->func
b21cdb9523e5561 Andy Chiu      2025-04-08  146  #else
b21cdb9523e5561 Andy Chiu      2025-04-08  147  	la	a1, function_trace_op
b21cdb9523e5561 Andy Chiu      2025-04-08  148  	REG_L	a2, 0(a1)			// op
b21cdb9523e5561 Andy Chiu      2025-04-08  149  	mv	a1, ra				// parent_ip
b21cdb9523e5561 Andy Chiu      2025-04-08  150  #endif
b21cdb9523e5561 Andy Chiu      2025-04-08  151  	mv	a3, sp				// regs
b21cdb9523e5561 Andy Chiu      2025-04-08  152  	.endm
b21cdb9523e5561 Andy Chiu      2025-04-08  153  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki