Ftrace broken on parisc

Ftrace broken on parisc

[Guy Martin]

Hi all,


It seems that the ftrace subsystem has not been maintained for a few
years.

So far I have the diff at the bottom that attempts to fix it bug there
is still an issue while linking :


arch/parisc/kernel/built-in.o: In function `return_to_handler':
(.text+0xb2a8): undefined reference to `ftrace_return_to_handler'
hppa64-linux-ld: arch/parisc/kernel/built-in.o(.text+0xllx): cannot
reach (null)
arch/parisc/kernel/built-in.o: In function `return_to_handler':
(.text+0xb2a8): relocation truncated to fit: R_PARISC_PCREL17F against
undefined symbol `ftrace_return_to_handler'
make: *** [vmlinux] Error 1

I'm not sure how this can be fixed, the problems comes from the
assembly in entry.S, it uses a 'b' to jump to ftrace_return_to_handler.
I guess 'be' needs to be used but not sure how that'd works with the
linker.

Moreover, there is probably more than this to be fixed.

For the background story, I'm trying to fix this to audit irq handlers
for my pata_sil680 issue.

Adding some printk for irq == 71 in handle_percpu_irq(), I see and odd
behavior. The printk at the end of the function is displayed a lot more
than the printk at the begining of the function. I know printk isn't
the best for irq handlers that's why I was investigating the ftrace way.

Any tip/help is very much welcome !

  Guy

---
diff --git a/arch/parisc/Kconfig.debug b/arch/parisc/Kconfig.debug
index bc989e5..6d23a1a 100644
--- a/arch/parisc/Kconfig.debug
+++ b/arch/parisc/Kconfig.debug
@@ -1,5 +1,8 @@
 menu "Kernel hacking"

+config TRACE_IRQFLAGS_SUPPORT
+       def_bool y
+
 source "lib/Kconfig.debug"

 config DEBUG_RODATA
diff --git a/arch/parisc/kernel/ftrace.c b/arch/parisc/kernel/ftrace.c
index 5beb97b..8c9f757 100644
--- a/arch/parisc/kernel/ftrace.c
+++ b/arch/parisc/kernel/ftrace.c
@@ -156,7 +156,7 @@ void ftrace_function_trampoline(unsigned long
 parent, return;

        if (ftrace_trace_function != ftrace_stub) {
-               ftrace_trace_function(parent, self_addr);
+               ftrace_trace_function(parent, self_addr, NULL, NULL);
                return;
        }
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER

Re: Ftrace broken on parisc

[Helge Deller]

Hi Guy,

On 01/29/2014 08:59 PM, Guy Martin wrote:
> It seems that the ftrace subsystem has not been maintained for a few
> years.

Yes.
 
> So far I have the diff at the bottom that attempts to fix it bug there
> is still an issue while linking :

I'm not sure I tested 64bit at that time.

> arch/parisc/kernel/built-in.o: In function `return_to_handler':
> (.text+0xb2a8): undefined reference to `ftrace_return_to_handler'
> hppa64-linux-ld: arch/parisc/kernel/built-in.o(.text+0xllx): cannot
> reach (null)
> arch/parisc/kernel/built-in.o: In function `return_to_handler':
> (.text+0xb2a8): relocation truncated to fit: R_PARISC_PCREL17F against
> undefined symbol `ftrace_return_to_handler'
> make: *** [vmlinux] Error 1
> 
> I'm not sure how this can be fixed, the problems comes from the
> assembly in entry.S, it uses a 'b' to jump to ftrace_return_to_handler.
> I guess 'be' needs to be used but not sure how that'd works with the
> linker.

Can you try
BL ftrace_return_to_handler, %r0
(I'm not good in hppa assembly - as you can see if you take a look at this assembly code section :-)).

> Moreover, there is probably more than this to be fixed.
> 
> For the background story, I'm trying to fix this to audit irq handlers
> for my pata_sil680 issue.
> 
> Adding some printk for irq == 71 in handle_percpu_irq(), I see and odd
> behavior. The printk at the end of the function is displayed a lot more
> than the printk at the begining of the function. I know printk isn't
> the best for irq handlers that's why I was investigating the ftrace way.
> 
> Any tip/help is very much welcome !

Helge


> 
>   Guy
> 
> ---
> diff --git a/arch/parisc/Kconfig.debug b/arch/parisc/Kconfig.debug
> index bc989e5..6d23a1a 100644
> --- a/arch/parisc/Kconfig.debug
> +++ b/arch/parisc/Kconfig.debug
> @@ -1,5 +1,8 @@
>  menu "Kernel hacking"
> 
> +config TRACE_IRQFLAGS_SUPPORT
> +       def_bool y
> +
>  source "lib/Kconfig.debug"
> 
>  config DEBUG_RODATA
> diff --git a/arch/parisc/kernel/ftrace.c b/arch/parisc/kernel/ftrace.c
> index 5beb97b..8c9f757 100644
> --- a/arch/parisc/kernel/ftrace.c
> +++ b/arch/parisc/kernel/ftrace.c
> @@ -156,7 +156,7 @@ void ftrace_function_trampoline(unsigned long
>  parent, return;
> 
>         if (ftrace_trace_function != ftrace_stub) {
> -               ftrace_trace_function(parent, self_addr);
> +               ftrace_trace_function(parent, self_addr, NULL, NULL);
>                 return;
>         }
>  #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Ftrace broken on parisc

[John David Anglin]

On 1/29/2014 3:44 PM, Helge Deller wrote:
> Hi Guy,
>
> On 01/29/2014 08:59 PM, Guy Martin wrote:
>> It seems that the ftrace subsystem has not been maintained for a few
>> years.
> Yes.
>   
>> So far I have the diff at the bottom that attempts to fix it bug there
>> is still an issue while linking :
> I'm not sure I tested 64bit at that time.
>
>> arch/parisc/kernel/built-in.o: In function `return_to_handler':
>> (.text+0xb2a8): undefined reference to `ftrace_return_to_handler'
>> hppa64-linux-ld: arch/parisc/kernel/built-in.o(.text+0xllx): cannot
>> reach (null)
>> arch/parisc/kernel/built-in.o: In function `return_to_handler':
>> (.text+0xb2a8): relocation truncated to fit: R_PARISC_PCREL17F against
>> undefined symbol `ftrace_return_to_handler'
>> make: *** [vmlinux] Error 1
>>
>> I'm not sure how this can be fixed, the problems comes from the
>> assembly in entry.S, it uses a 'b' to jump to ftrace_return_to_handler.
>> I guess 'be' needs to be used but not sure how that'd works with the
>> linker.
> Can you try
> BL ftrace_return_to_handler, %r0
> (I'm not good in hppa assembly - as you can see if you take a look at this assembly code section :-)).
>
BL might not reach on PA 1.1.  The PA 2.0 b,l instruction is only "long" 
when the link
register is %rp and it is used for the return_trampoline.

I would say replace "b" with the following as it will always reach target:
         load32  ftrace_return_to_handler, %r20
         bv      %r0(%r20)

%r1 is another register alternative.

Dave

-- 
John David Anglin    dave.anglin@bell.net

Re: Ftrace broken on parisc

[Guy Martin]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

On Wed, 29 Jan 2014 16:09:24 -0500
John David Anglin <dave.anglin@bell.net> wrote:

> On 1/29/2014 3:44 PM, Helge Deller wrote:
> > Can you try
> > BL ftrace_return_to_handler, %r0
> > (I'm not good in hppa assembly - as you can see if you take a look
> > at this assembly code section :-)).
> >
> BL might not reach on PA 1.1.  The PA 2.0 b,l instruction is only
> "long" when the link
> register is %rp and it is used for the return_trampoline.
> 
> I would say replace "b" with the following as it will always reach
> target: load32  ftrace_return_to_handler, %r20
>          bv      %r0(%r20)
> 
> %r1 is another register alternative.


Thanks, however, I later found out that this part of the code isn't
used if you set CONFIG_FUNCTION_GRAPH_TRACER=n.


In my config, I've enabled only this :
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y

Full config can be found here : http://bpaste.net/show/178555/


So far I came up with the attached patch to try to get a booting kernel
but I don't even have the first line being printed, the box HPMC and
reboot.


As far as I understand, compiling with -pg will make each function jump
to _mcount before being actually executed. This is why I tried to make
the _mcount function simply jump back to %rp but this doesn't seem to
be helpful.


What am I missing here ?

  GUy

[-- Attachment #2: ftrace-test.patch --]
[-- Type: text/x-patch, Size: 1688 bytes --]

diff --git a/arch/parisc/Kconfig.debug b/arch/parisc/Kconfig.debug
index bc989e5..6d23a1a 100644
--- a/arch/parisc/Kconfig.debug
+++ b/arch/parisc/Kconfig.debug
@@ -1,5 +1,8 @@
 menu "Kernel hacking"
 
+config TRACE_IRQFLAGS_SUPPORT
+	def_bool y
+
 source "lib/Kconfig.debug"
 
 config DEBUG_RODATA
diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
index e8f07dd..bdb4d33 100644
--- a/arch/parisc/kernel/entry.S
+++ b/arch/parisc/kernel/entry.S
@@ -1999,11 +1999,15 @@ ENDPROC(syscall_exit)
 #ifdef CONFIG_FUNCTION_TRACER
 	.import ftrace_function_trampoline,code
 ENTRY(_mcount)
+	bv	%r0(%rp)
+	nop
+	/* not reached */
 	copy	%r3, %arg2
 	b	ftrace_function_trampoline
 	nop
 ENDPROC(_mcount)
 
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
 ENTRY(return_to_handler)
 	load32	return_trampoline, %rp
 	copy	%ret0, %arg0
@@ -2019,7 +2023,19 @@ return_trampoline:
 ftrace_stub:
 	bv	%r0(%rp)
 	nop
+#else /* CONFIG_FUNCTION_GRAPH_TRACER */
+
+ENTRY(ftrace_stub)
+	bv	%r0(%rp)
+	nop
+ENDPROC(ftrace_stub)
+
+#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
+
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
 ENDPROC(return_to_handler)
+#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
+
 #endif	/* CONFIG_FUNCTION_TRACER */
 
 #ifdef CONFIG_IRQSTACKS
diff --git a/arch/parisc/kernel/ftrace.c b/arch/parisc/kernel/ftrace.c
index 5beb97b..8c9f757 100644
--- a/arch/parisc/kernel/ftrace.c
+++ b/arch/parisc/kernel/ftrace.c
@@ -156,7 +156,7 @@ void ftrace_function_trampoline(unsigned long parent,
 		return;
 
 	if (ftrace_trace_function != ftrace_stub) {
-		ftrace_trace_function(parent, self_addr);
+		ftrace_trace_function(parent, self_addr, NULL, NULL);
 		return;
 	}
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER