[RFC] ARC: initial ftrace support

[RFC] ARC: initial ftrace support

[Eugeniy Paltsev]

Add initial ftrace support for ARCv2. We add support only for
function tracer (the simplest, not dynamic one), however it is
prerequisite for dynamic function tracer and other complex
ones.

Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
---
 arch/arc/Kconfig              |  1 +
 arch/arc/include/asm/Kbuild   |  1 -
 arch/arc/include/asm/ftrace.h | 16 ++++++++++++++++
 arch/arc/kernel/Makefile      | 10 ++++++++++
 arch/arc/kernel/ftrace.c      | 27 +++++++++++++++++++++++++++
 5 files changed, 54 insertions(+), 1 deletion(-)
 create mode 100644 arch/arc/include/asm/ftrace.h
 create mode 100644 arch/arc/kernel/ftrace.c

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index ff2a393b635c..4b8f750bd32b 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -48,6 +48,7 @@ config ARC
 	select PCI_SYSCALL if PCI
 	select PERF_USE_VMALLOC if ARC_CACHE_VIPT_ALIASING
 	select HAVE_ARCH_JUMP_LABEL if ISA_ARCV2 && !CPU_ENDIAN_BE32
+	select HAVE_FUNCTION_TRACER if ISA_ARCV2
 
 config ARCH_HAS_CACHE_LINE_SIZE
 	def_bool y
diff --git a/arch/arc/include/asm/Kbuild b/arch/arc/include/asm/Kbuild
index 1b505694691e..4e2f55bdf2ff 100644
--- a/arch/arc/include/asm/Kbuild
+++ b/arch/arc/include/asm/Kbuild
@@ -6,7 +6,6 @@ generic-y += div64.h
 generic-y += dma-mapping.h
 generic-y += emergency-restart.h
 generic-y += extable.h
-generic-y += ftrace.h
 generic-y += hardirq.h
 generic-y += hw_irq.h
 generic-y += irq_regs.h
diff --git a/arch/arc/include/asm/ftrace.h b/arch/arc/include/asm/ftrace.h
new file mode 100644
index 000000000000..92303e506edf
--- /dev/null
+++ b/arch/arc/include/asm/ftrace.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2020 Synopsys, Inc. (www.synopsys.com)
+ *
+ * Author: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
+ */
+
+#ifndef __ASM_ARC_FTRACE_H
+#define __ASM_ARC_FTRACE_H
+
+extern void _mcount(unsigned long parent_ip);
+
+/* 3 instructions 1x 16 bit + 1x 32 bit */
+#define MCOUNT_INSN_SIZE	6
+
+#endif /* __ASM_ARC_FTRACE_H */
diff --git a/arch/arc/kernel/Makefile b/arch/arc/kernel/Makefile
index 75539670431a..42c9c4b1cabd 100644
--- a/arch/arc/kernel/Makefile
+++ b/arch/arc/kernel/Makefile
@@ -22,12 +22,22 @@ obj-$(CONFIG_ARC_METAWARE_HLINK)	+= arc_hostlink.o
 obj-$(CONFIG_PERF_EVENTS)		+= perf_event.o
 obj-$(CONFIG_JUMP_LABEL)		+= jump_label.o
 
+
+obj-$(CONFIG_FUNCTION_TRACER)		+= ftrace.o
+
+ifdef CONFIG_FUNCTION_TRACER
+CFLAGS_REMOVE_ftrace.o = $(CC_FLAGS_FTRACE)
+endif
+
 obj-$(CONFIG_ARC_FPU_SAVE_RESTORE)	+= fpu.o
 ifdef CONFIG_ISA_ARCOMPACT
 CFLAGS_fpu.o   += -mdpfp
 endif
 
 ifdef CONFIG_ARC_DW2_UNWIND
+ifdef CONFIG_FUNCTION_TRACER
+CFLAGS_REMOVE_ctx_sw.o = $(CC_FLAGS_FTRACE)
+endif
 CFLAGS_ctx_sw.o += -fno-omit-frame-pointer
 obj-y += ctx_sw.o
 else
diff --git a/arch/arc/kernel/ftrace.c b/arch/arc/kernel/ftrace.c
new file mode 100644
index 000000000000..a61edf52bfe2
--- /dev/null
+++ b/arch/arc/kernel/ftrace.c
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 Synopsys, Inc. (www.synopsys.com)
+ *
+ * Author: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
+ */
+
+#include <linux/ftrace.h>
+
+noinline void ftrace_stub(unsigned long ip, unsigned long parent_ip,
+			  struct ftrace_ops *op, struct pt_regs *regs)
+{
+	/* do notning */
+}
+
+extern void (*ftrace_trace_function)(unsigned long, unsigned long,
+				     struct ftrace_ops*, struct pt_regs*);
+
+noinline void _mcount(unsigned long parent_ip)
+{
+	unsigned long ip = (unsigned long)__builtin_return_address(0);
+
+	if (unlikely(ftrace_trace_function != ftrace_stub))
+		ftrace_trace_function(ip - MCOUNT_INSN_SIZE, parent_ip,
+				      NULL, NULL);
+}
+EXPORT_SYMBOL(_mcount);
-- 
2.21.1

Re: [RFC] ARC: initial ftrace support

[Steven Rostedt]

On Fri, 27 Mar 2020 18:53:55 +0300
Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> wrote:

> +
> +noinline void _mcount(unsigned long parent_ip)
> +{
> +	unsigned long ip = (unsigned long)__builtin_return_address(0);
> +
> +	if (unlikely(ftrace_trace_function != ftrace_stub))
> +		ftrace_trace_function(ip - MCOUNT_INSN_SIZE, parent_ip,
> +				      NULL, NULL);
> +}
> +EXPORT_SYMBOL(_mcount);

So, ARCv2 allows the _mcount code to be written in C? Nice!

-- Steve

Re: [RFC] ARC: initial ftrace support

[Vineet Gupta]

+CC Claudiu

On 3/27/20 10:10 AM, Steven Rostedt wrote:
> On Fri, 27 Mar 2020 18:53:55 +0300
> Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> wrote:

Maybe add a comment that gcc does the heavy lifting: I have following in glibc

+/* this is very simple as gcc does all the heavy lifting at _mcount call site
+ *  - sets up caller's blink in r0, so frompc is setup correctly
+ *  - preserve argument registers for original call */

>> +noinline void _mcount(unsigned long parent_ip)
>> +{
>> +	unsigned long ip = (unsigned long)__builtin_return_address(0);
>> +
>> +	if (unlikely(ftrace_trace_function != ftrace_stub))
>> +		ftrace_trace_function(ip - MCOUNT_INSN_SIZE, parent_ip,
>> +				      NULL, NULL);
>> +}
>> +EXPORT_SYMBOL(_mcount);
> 
> So, ARCv2 allows the _mcount code to be written in C? Nice!

Yeah, the gcc backend for -pg was overhauled recently so it is a first class "lib
call" meaning we get all the register save/restore for free as well as caller PC
(blink) as explicit argument to _mcount

void bar(int a, int b, int c) {
	printf("%d\n", a, b, c);
}

bar:
	push_s	blink
	std.a r14,[sp,-8]
	push_s	r13
	mov_s	r14,r1
	mov_s	r13,r0
	mov_s	r0,blink
	bl.d @_mcount
	mov_s	r15,r2

	mov_s	r3,r15   <-- restore args for call
	mov_s	r2,r14
	mov_s	r1,r13
	mov_s	r0,@.LC0
	ld	blink,[sp,12]
	pop_s	r13
	b.d	@printf
	ldd.ab r14,[sp,12]

@Eugeniy, this patch looks ok to me, but a word of caution. This won't work with
elf32 toolchain which some of the build systems tend to use (Alexey ?)

The above _mcount semantics is only implemented for the linux tool-chains.
elf32-gcc generates "legacy" __mcount (2 underscores, blink not provided as arg)
likely done by Claudiu to keep newlib stuff unchanged. Perhaps elf32 gcc can add a
toggle to get new _mcount.

And this is conditional to ARCv2 due to future ties into dynamic ftrace and
instruction fudging etc ? We may have to revisit that for BE anyhow given such a
customer lining up.

-Vineet

Re: [RFC] ARC: initial ftrace support

[Claudiu Zissulescu Ianculescu]

Hi,

ARC-gcc has two modes to call the mcount routines. When using elf32
configuration, the toolchain is set to use newlib mcount. When
configured for linux, gcc toolchain is using a library call to _mcall
(single underscore)  having blink as input argument.
So, using the proper linux toolchain, your patch should work.

//C

On Thu, Apr 2, 2020 at 4:17 AM Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:
>
> +CC Claudiu
>
> On 3/27/20 10:10 AM, Steven Rostedt wrote:
> > On Fri, 27 Mar 2020 18:53:55 +0300
> > Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> wrote:
>
> Maybe add a comment that gcc does the heavy lifting: I have following in glibc
>
> +/* this is very simple as gcc does all the heavy lifting at _mcount call site
> + *  - sets up caller's blink in r0, so frompc is setup correctly
> + *  - preserve argument registers for original call */
>
> >> +noinline void _mcount(unsigned long parent_ip)
> >> +{
> >> +    unsigned long ip = (unsigned long)__builtin_return_address(0);
> >> +
> >> +    if (unlikely(ftrace_trace_function != ftrace_stub))
> >> +            ftrace_trace_function(ip - MCOUNT_INSN_SIZE, parent_ip,
> >> +                                  NULL, NULL);
> >> +}
> >> +EXPORT_SYMBOL(_mcount);
> >
> > So, ARCv2 allows the _mcount code to be written in C? Nice!
>
> Yeah, the gcc backend for -pg was overhauled recently so it is a first class "lib
> call" meaning we get all the register save/restore for free as well as caller PC
> (blink) as explicit argument to _mcount
>
> void bar(int a, int b, int c) {
>         printf("%d\n", a, b, c);
> }
>
> bar:
>         push_s  blink
>         std.a r14,[sp,-8]
>         push_s  r13
>         mov_s   r14,r1
>         mov_s   r13,r0
>         mov_s   r0,blink
>         bl.d @_mcount
>         mov_s   r15,r2
>
>         mov_s   r3,r15   <-- restore args for call
>         mov_s   r2,r14
>         mov_s   r1,r13
>         mov_s   r0,@.LC0
>         ld      blink,[sp,12]
>         pop_s   r13
>         b.d     @printf
>         ldd.ab r14,[sp,12]
>
> @Eugeniy, this patch looks ok to me, but a word of caution. This won't work with
> elf32 toolchain which some of the build systems tend to use (Alexey ?)
>
> The above _mcount semantics is only implemented for the linux tool-chains.
> elf32-gcc generates "legacy" __mcount (2 underscores, blink not provided as arg)
> likely done by Claudiu to keep newlib stuff unchanged. Perhaps elf32 gcc can add a
> toggle to get new _mcount.
>
> And this is conditional to ARCv2 due to future ties into dynamic ftrace and
> instruction fudging etc ? We may have to revisit that for BE anyhow given such a
> customer lining up.
>
> -Vineet

RE: [RFC] ARC: initial ftrace support

[Alexey Brodkin]

Hi Claus,

> -----Original Message-----
> From: linux-snps-arc <linux-snps-arc-bounces@lists.infradead.org> On Behalf Of Claudiu Zissulescu
> Ianculescu
> Sent: Thursday, April 2, 2020 11:10 AM
> To: Vineet Gupta <vgupta@synopsys.com>
> Cc: Alexey Brodkin <abrodkin@synopsys.com>; linux-kernel@vger.kernel.org; Steven Rostedt
> <rostedt@goodmis.org>; Ingo Molnar <mingo@redhat.com>; linux-snps-arc@lists.infradead.org; Eugeniy
> Paltsev <paltsev@synopsys.com>
> Subject: Re: [RFC] ARC: initial ftrace support
> 
> Hi,
> 
> ARC-gcc has two modes to call the mcount routines. When using elf32
> configuration, the toolchain is set to use newlib mcount. When
> configured for linux, gcc toolchain is using a library call to _mcall
> (single underscore)  having blink as input argument.
> So, using the proper linux toolchain, your patch should work.


Is there a chance to switch to Linux-style mcount in Elf32 toolchain with a command-line
option?

Otherwise I guess we'll need to implement some warning which explicitly says why Elf32
toolchain is not usable for building the Linux kernel... at least in case with ftrace enabled.

-Alexey

Re: [RFC] ARC: initial ftrace support

[Steven Rostedt]

On Thu, 2 Apr 2020 01:17:01 +0000
Vineet Gupta <Vineet.Gupta1@synopsys.com> wrote:

> +CC Claudiu
> 
> On 3/27/20 10:10 AM, Steven Rostedt wrote:
> > On Fri, 27 Mar 2020 18:53:55 +0300
> > Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> wrote:  
> 
> Maybe add a comment that gcc does the heavy lifting: I have following in glibc
> 
> +/* this is very simple as gcc does all the heavy lifting at _mcount call site
> + *  - sets up caller's blink in r0, so frompc is setup correctly
> + *  - preserve argument registers for original call */
> 
> >> +noinline void _mcount(unsigned long parent_ip)
> >> +{
> >> +	unsigned long ip = (unsigned long)__builtin_return_address(0);
> >> +
> >> +	if (unlikely(ftrace_trace_function != ftrace_stub))
> >> +		ftrace_trace_function(ip - MCOUNT_INSN_SIZE, parent_ip,
> >> +				      NULL, NULL);
> >> +}
> >> +EXPORT_SYMBOL(_mcount);  
> > 
> > So, ARCv2 allows the _mcount code to be written in C? Nice!  
> 
> Yeah, the gcc backend for -pg was overhauled recently so it is a first class "lib
> call" meaning we get all the register save/restore for free as well as caller PC
> (blink) as explicit argument to _mcount
> 
> void bar(int a, int b, int c) {
> 	printf("%d\n", a, b, c);
> }
> 
> bar:
> 	push_s	blink
> 	std.a r14,[sp,-8]
> 	push_s	r13
> 	mov_s	r14,r1
> 	mov_s	r13,r0
> 	mov_s	r0,blink
> 	bl.d @_mcount
> 	mov_s	r15,r2
> 
> 	mov_s	r3,r15   <-- restore args for call

We really don't want this. :-/

This will make it really difficult to implement the dynamic ftrace, and
this causes more overhead when tracing is not enabled.

Also, ftrace is much more complex, and this will make it difficult to have
function graph tracing and other features.

Gcc has an "instrument-functions" which people asked me why I didn't go
that route, as it lets you do the same (call C code), and its because of
the overhead it adds to each function that I turned it down.

-- Steve



> 	mov_s	r2,r14
> 	mov_s	r1,r13
> 	mov_s	r0,@.LC0
> 	ld	blink,[sp,12]
> 	pop_s	r13
> 	b.d	@printf
> 	ldd.ab r14,[sp,12]
> 
> @Eugeniy, this patch looks ok to me, but a word of caution. This won't work with
> elf32 toolchain which some of the build systems tend to use (Alexey ?)
> 
> The above _mcount semantics is only implemented for the linux tool-chains.
> elf32-gcc generates "legacy" __mcount (2 underscores, blink not provided as arg)
> likely done by Claudiu to keep newlib stuff unchanged. Perhaps elf32 gcc can add a
> toggle to get new _mcount.
> 
> And this is conditional to ARCv2 due to future ties into dynamic ftrace and
> instruction fudging etc ? We may have to revisit that for BE anyhow given such a
> customer lining up.
> 
> -Vineet

Re: [RFC] ARC: initial ftrace support

[Eugeniy Paltsev]

Hi Claudiu,
ping!

Is is possible to switch between mcount modes (Linux-style <-> baremetal-style) via command-line options for ARC GCC?

>From: Alexey Brodkin <abrodkin@synopsys.com>
>Sent: Thursday, April 2, 2020 17:15
>To: Claudiu Zissulescu Ianculescu
>Cc: linux-kernel@vger.kernel.org; Steven Rostedt; Ingo Molnar; linux-snps-arc@lists.infradead.org; Eugeniy Paltsev; Vineet Gupta
>Subject: RE: [RFC] ARC: initial ftrace support
>
> Hi Claus,
>
>> -----Original Message-----
>> From: linux-snps-arc <linux-snps-arc-bounces@lists.infradead.org> On Behalf Of Claudiu Zissulescu
>> Ianculescu
>> Sent: Thursday, April 2, 2020 11:10 AM
>> To: Vineet Gupta <vgupta@synopsys.com>
>> Cc: Alexey Brodkin <abrodkin@synopsys.com>; linux-kernel@vger.kernel.org; Steven Rostedt
>> <rostedt@goodmis.org>; Ingo Molnar <mingo@redhat.com>; linux-snps-arc@lists.infradead.org; Eugeniy
>> Paltsev <paltsev@synopsys.com>
>> Subject: Re: [RFC] ARC: initial ftrace support
>>
>> Hi,
>>
>> ARC-gcc has two modes to call the mcount routines. When using elf32
>> configuration, the toolchain is set to use newlib mcount. When
>> configured for linux, gcc toolchain is using a library call to _mcall
>> (single underscore)  having blink as input argument.
>> So, using the proper linux toolchain, your patch should work.
>
>
> Is there a chance to switch to Linux-style mcount in Elf32 toolchain with a command-line
> option?
>
> Otherwise I guess we'll need to implement some warning which explicitly says why Elf32
> toolchain is not usable for building the Linux kernel... at least in case with ftrace enabled.
>
>-Alexey