From: "[email protected]" <[email protected]>
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/[email protected]/
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/[email protected]
Cc: Yoshinori Sato <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: [email protected]
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
---
arch/sh/boot/compressed/misc.c | 3 +++
1 file changed, 3 insertions(+)
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
--
2.33.0
On 26.10.2021 19:23, Steven Rostedt wrote:
> From: "[email protected]" <[email protected]>
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/[email protected]/
>
> 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/[email protected]
>
> Cc: Yoshinori Sato <[email protected]>
> Cc: Rich Felker <[email protected]>
> Cc: [email protected]
> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
[...]
MBR, Sergey
On Wed, 27 Oct 2021 11:58:31 +0300
Sergey Shtylyov <[email protected]> wrote:
> > From: "[email protected]" <[email protected]>
>
> 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