[for-next,10/12] ftrace/sh: Add arch_ftrace_ops_list_func stub to have compressed image still link

Commit Message

Steven Rostedt Oct. 26, 2021, 4:23 p.m. UTC

From: "[e-mail]" <[e-mail]>

Using the linker script to fix an issue where some archs call the
function tracer with just the ip (instruction pointer) and pip (parent
instruction pointer) where as more up to date archs also pass in the
associated ftrace_ops and the ftrace_regs pointer, the generic code
will be called either with two parameters or four. To avoid any C
undefined behavior of calling two parameters to four or four to two
parameter function, two functions are created, where a preprocessor
macro uses the one that matches the architecture. As the function
pointers for them may be different, a typecast is used. But this
triggers issues with newer compilers that will fail due to -Werror.

A linker trick is now used to map the generic function to the function
that is used (note the generic function is only used to set the default
function callback). The linker trick defines ftrace_ops_list_func (the
generic function) to arch_ftrace_ops_list_func (the arch defined one).

Link: https://lore.kernel.org/all/[e-mail]/

But this fails sh arch because their linker script is included in their
compressed image that does not define arch_ftrace_ops_list_func at all

  sh4-linux-ld:arch/sh/boot/compressed/../../kernel/vmlinux.lds:32: undefined symbol `arch_ftrace_ops_list_func' referenced in expression

Included a stub by that name in the misc.c to allow the code to
compile and link, even though it's not used.

This is similar to what was done for ftrace_stub:

  b83b43ffc6e4b ("fgraph: Fix function type mismatches of
  ftrace_graph_return using ftrace_stub")

Link: https://lkml.kernel.org/r/[e-mail]

Cc: Yoshinori Sato <[e-mail]>
Cc: Rich Felker <[e-mail]>
Cc: [e-mail]
Signed-off-by: Steven Rostedt (VMware) <[e-mail]>
---
 arch/sh/boot/compressed/misc.c | 3 +++
 1 file changed, 3 insertions(+)

Comments

Sergey Shtylyov Oct. 27, 2021, 8:58 a.m. UTC | #1

On 26.10.2021 19:23, Steven Rostedt wrote:

> From: "[e-mail]" <[e-mail]>

    Collective author, really? :-)

> Using the linker script to fix an issue where some archs call the
> function tracer with just the ip (instruction pointer) and pip (parent
> instruction pointer) where as more up to date archs also pass in the
> associated ftrace_ops and the ftrace_regs pointer, the generic code
> will be called either with two parameters or four. To avoid any C
> undefined behavior of calling two parameters to four or four to two
> parameter function, two functions are created, where a preprocessor
> macro uses the one that matches the architecture. As the function
> pointers for them may be different, a typecast is used. But this
> triggers issues with newer compilers that will fail due to -Werror.
> 
> A linker trick is now used to map the generic function to the function
> that is used (note the generic function is only used to set the default
> function callback). The linker trick defines ftrace_ops_list_func (the
> generic function) to arch_ftrace_ops_list_func (the arch defined one).
> 
> Link: https://lore.kernel.org/all/[e-mail]/
> 
> But this fails sh arch because their linker script is included in their
> compressed image that does not define arch_ftrace_ops_list_func at all
> 
>    sh4-linux-ld:arch/sh/boot/compressed/../../kernel/vmlinux.lds:32: undefined symbol `arch_ftrace_ops_list_func' referenced in expression
> 
> Included a stub by that name in the misc.c to allow the code to
> compile and link, even though it's not used.
> 
> This is similar to what was done for ftrace_stub:
> 
>    b83b43ffc6e4b ("fgraph: Fix function type mismatches of
>    ftrace_graph_return using ftrace_stub")
> 
> Link: https://lkml.kernel.org/r/[e-mail]
> 
> Cc: Yoshinori Sato <[e-mail]>
> Cc: Rich Felker <[e-mail]>
> Cc: [e-mail]
> Signed-off-by: Steven Rostedt (VMware) <[e-mail]>
[...]

MBR, Sergey

Steven Rostedt Oct. 27, 2021, 12:01 p.m. UTC | #2

On Wed, 27 Oct 2021 11:58:31 +0300
Sergey Shtylyov <[e-mail]> wrote:

> > From: "[e-mail]" <[e-mail]>  
> 
>     Collective author, really? :-)

Yeah, Stephen already pointed this that the author didn't have a
"signed-off-by", when in reality my patchwork (which I send my own patches
through) somehow add that as the author and not me :-p

-- Steve

Patch

diff --git a/arch/sh/boot/compressed/misc.c b/arch/sh/boot/compressed/misc.c
index a03b6680a9d9..ca05c99a3d5b 100644
--- a/arch/sh/boot/compressed/misc.c
+++ b/arch/sh/boot/compressed/misc.c
@@ -115,6 +115,9 @@  void __stack_chk_fail(void)
 void ftrace_stub(void)
 {
 }
+void arch_ftrace_ops_list_func(void)
+{
+}
 
 #define stackalign	4