Skip to contentSkip to conversation

Ftrace broken on parisc

PATCH Guy Martin 3 participants 4 messages Jan 29, 2014 – Feb 12, 2014

Subsystems (2)
PA-RISC architecture ftrace
lore
Share & tools
lore

Guy Martin

author
#0 lore raw

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

---

arch/parisc/Kconfig.debug +3 -0
index bc989e5..6d23a1a 100644
@@ -1,5 +1,8 @@
 menu "Kernel hacking"
 
+config TRACE_IRQFLAGS_SUPPORT
+       def_bool y
+
 source "lib/Kconfig.debug"
 
 config DEBUG_RODATA
arch/parisc/kernel/ftrace.c +1 -1
index 5beb97b..8c9f757 100644
@@ -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
maintainer
#1 lore raw

Hi Guy,

Quoted 2 lines · Guy Martin

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

Yes.

Quoted 2 lines

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.

Quoted 9 lines

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

Quoted 4 lines

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 :-)).

Quoted 11 lines

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

Quoted 36 lines

Guy

---

arch/parisc/Kconfig.debug +3 -0
index bc989e5..6d23a1a 100644
@@ -1,5 +1,8 @@
 menu "Kernel hacking"
 
+config TRACE_IRQFLAGS_SUPPORT
+       def_bool y
+
 source "lib/Kconfig.debug"
 
 config DEBUG_RODATA
arch/parisc/kernel/ftrace.c +1 -2
index 5beb97b..8c9f757 100644
@@ -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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#2 lore raw
Quoted 20 lines · Helge Deller

Hi Guy,

Quoted 2 lines · Guy Martin

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

Yes.

Quoted 2 lines

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.

Quoted 9 lines

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

Quoted 8 lines
Quoted 4 lines

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

Signature · 1 line
John David Anglin    [email protected]
author
#3 lore raw
Quoted 10 lines · On Wed, 29 Jan 2014 16:09:24 -0500 John David Anglin <[email protected]>…
Quoted 5 lines · Helge Deller

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.

Quoted 5 lines

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

arch/parisc/Kconfig.debug +3 -0
index bc989e5..6d23a1a 100644
@@ -1,5 +1,8 @@
 menu "Kernel hacking"
 
+config TRACE_IRQFLAGS_SUPPORT
+	def_bool y
+
 source "lib/Kconfig.debug"
 
 config DEBUG_RODATA
arch/parisc/kernel/entry.S +16 -0
index e8f07dd..bdb4d33 100644
@@ -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
arch/parisc/kernel/ftrace.c +1 -1
index 5beb97b..8c9f757 100644
@@ -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