* [PATCH] Make Function Duration Tracer work with __gnu_mcount_nc
@ 2010-03-19 21:43 Ashwin Chaugule
2010-03-19 21:53 ` Tim Bird
0 siblings, 1 reply; 3+ messages in thread
From: Ashwin Chaugule @ 2010-03-19 21:43 UTC (permalink / raw)
To: Tim Bird, Frederic Weisbecker, Steven Rostedt
Cc: linux-arm-kernel, linux kernel, linux-arm-msm
Is there a better way to fix this in the original ftrace_graph_caller ?
The lr isn't pushed on the stack before "bl mcount".
--
From: Ashwin Chaugule <ashwinc@quicinc.com>
Newer compilers use the __gnu_mcount_nc stub in every function
prologue. The lr of the instrumented function is pushed on the
stack before branching to __gnu_mcount_nc. Pop it before returning
back to instrumented function so that it can return to its parent
from its epilogue.
Signed-off-by: Ashwin Chaugule <ashwinc@quicinc.com>
---
arch/arm/kernel/entry-common.S | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index b8a9e47..30feac3 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -144,6 +144,14 @@ ENTRY(__gnu_mcount_nc)
adr r0, ftrace_stub
cmp r0, r2
bne gnu_trace
+
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+ ldr r1, =ftrace_graph_return
+ ldr r2, [r1]
+ cmp r0, r2 @ if *ftrace_graph_return != ftrace_stub
+ bne new_ftrace_graph_caller
+#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
+
ldmia sp!, {r0-r3, ip, lr}
bx ip
@@ -155,6 +163,18 @@ gnu_trace:
mov pc, r2
ldmia sp!, {r0-r3, ip, lr}
bx ip
+
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+ENTRY(new_ftrace_graph_caller) @ for use with __gnu_mcount_nc
+ sub r0, fp, #4 @ &lr of instrumented routine
(&parent)
+ mov r1, lr @ instrumented routine (func)
+ sub r1, r1, #MCOUNT_INSN_SIZE
+ mov r2, fp @ frame pointer
+ bl prepare_ftrace_return
+ ldmia sp!, {r0-r3, ip, lr} @ need to pop lr, pushed before
+ mov pc, ip @ bl __gnu_mcount_nc
+
+#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
ENTRY(mcount)
stmdb sp!, {r0-r3, lr}
--
1.5.6.3
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] Make Function Duration Tracer work with __gnu_mcount_nc
2010-03-19 21:43 [PATCH] Make Function Duration Tracer work with __gnu_mcount_nc Ashwin Chaugule
@ 2010-03-19 21:53 ` Tim Bird
2010-03-19 22:03 ` Ashwin Chaugule
0 siblings, 1 reply; 3+ messages in thread
From: Tim Bird @ 2010-03-19 21:53 UTC (permalink / raw)
To: Ashwin Chaugule
Cc: Bird, Tim, Frederic Weisbecker, Steven Rostedt, linux-arm-kernel,
linux kernel, linux-arm-msm@vger.kernel.org
On 03/19/2010 02:43 PM, Ashwin Chaugule wrote:
> Is there a better way to fix this in the original ftrace_graph_caller ?
> The lr isn't pushed on the stack before "bl mcount".
>
> --
>
> From: Ashwin Chaugule <ashwinc@quicinc.com>
>
> Newer compilers use the __gnu_mcount_nc stub in every function
> prologue. The lr of the instrumented function is pushed on the
> stack before branching to __gnu_mcount_nc. Pop it before returning
> back to instrumented function so that it can return to its parent
> from its epilogue.
>
>
> Signed-off-by: Ashwin Chaugule <ashwinc@quicinc.com>
> ---
> arch/arm/kernel/entry-common.S | 20 ++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
> index b8a9e47..30feac3 100644
> --- a/arch/arm/kernel/entry-common.S
> +++ b/arch/arm/kernel/entry-common.S
> @@ -144,6 +144,14 @@ ENTRY(__gnu_mcount_nc)
> adr r0, ftrace_stub
> cmp r0, r2
> bne gnu_trace
> +
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> + ldr r1, =ftrace_graph_return
> + ldr r2, [r1]
> + cmp r0, r2 @ if *ftrace_graph_return != ftrace_stub
> + bne new_ftrace_graph_caller
> +#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
> +
> ldmia sp!, {r0-r3, ip, lr}
> bx ip
>
> @@ -155,6 +163,18 @@ gnu_trace:
> mov pc, r2
> ldmia sp!, {r0-r3, ip, lr}
> bx ip
> +
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> +ENTRY(new_ftrace_graph_caller) @ for use with __gnu_mcount_nc
> + sub r0, fp, #4 @ &lr of instrumented routine
> (&parent)
> + mov r1, lr @ instrumented routine (func)
> + sub r1, r1, #MCOUNT_INSN_SIZE
> + mov r2, fp @ frame pointer
> + bl prepare_ftrace_return
> + ldmia sp!, {r0-r3, ip, lr} @ need to pop lr, pushed before
> + mov pc, ip @ bl __gnu_mcount_nc
> +
> +#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
>
> ENTRY(mcount)
> stmdb sp!, {r0-r3, lr}
Wow, interesting timing. I just finished yesterday my own
version of this patch (for 2.6.29) - it looks amazingingly similar.
What's up with putting fp in r2 - is that required in the latest
prepare_ftrace_return()?
-- Tim
------------- patch follows ----------------
Add support to __gnu_mcount_nc, used by newer (4.x?) Gnu compilers,
for ftrace function_graph support on ARM.
Signed-off-by: Tim Bird <tim.bird@am.sony.com>
---
arch/arm/kernel/entry-common.S | 13 +++++++++++++
1 file changed, 13 insertions(+)
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -140,6 +140,12 @@ ENTRY(__gnu_mcount_nc)
adr r0, ftrace_stub
cmp r0, r2
bne gnu_trace
+#ifdef CONFIG_FUNCTION_GRAPH_TRACER
+ ldr r1, =ftrace_graph_return
+ ldr r2, [r1]
+ cmp r0, r2 @ if *ftrace_graph_return != ftrace_stub
+ bne gnu_ftrace_graph_caller
+#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
ldmia sp!, {r0-r3, ip, lr}
bx ip
@@ -196,6 +202,13 @@ return_to_handler:
ldmia sp!, {r0-r3}
mov pc, lr
+ENTRY(gnu_ftrace_graph_caller)
+ sub r0, fp, #4 @ &lr of instrumented routine (&parent)
+ sub r1, lr, #MCOUNT_INSN_SIZE @ instrumented routine (func)
+ bl prepare_ftrace_return
+ ldmia sp!, {r0-r3, ip, lr}
+ bx ip
+
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
#endif /* CONFIG_DYNAMIC_FTRACE */
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Make Function Duration Tracer work with __gnu_mcount_nc
2010-03-19 21:53 ` Tim Bird
@ 2010-03-19 22:03 ` Ashwin Chaugule
0 siblings, 0 replies; 3+ messages in thread
From: Ashwin Chaugule @ 2010-03-19 22:03 UTC (permalink / raw)
To: Tim Bird
Cc: Bird, Tim, Frederic Weisbecker, Steven Rostedt, linux-arm-kernel,
linux kernel, linux-arm-msm@vger.kernel.org
Tim Bird wrote:
> On 03/19/2010 02:43 PM, Ashwin Chaugule wrote:
>
>> Is there a better way to fix this in the original ftrace_graph_caller ?
>> The lr isn't pushed on the stack before "bl mcount".
>>
>> --
>>
>> From: Ashwin Chaugule <ashwinc@quicinc.com>
>>
>> Newer compilers use the __gnu_mcount_nc stub in every function
>> prologue. The lr of the instrumented function is pushed on the
>> stack before branching to __gnu_mcount_nc. Pop it before returning
>> back to instrumented function so that it can return to its parent
>> from its epilogue.
>>
>>
>> Signed-off-by: Ashwin Chaugule <ashwinc@quicinc.com>
>> ---
>> arch/arm/kernel/entry-common.S | 20 ++++++++++++++++++++
>> 1 files changed, 20 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
>> index b8a9e47..30feac3 100644
>> --- a/arch/arm/kernel/entry-common.S
>> +++ b/arch/arm/kernel/entry-common.S
>> @@ -144,6 +144,14 @@ ENTRY(__gnu_mcount_nc)
>> adr r0, ftrace_stub
>> cmp r0, r2
>> bne gnu_trace
>> +
>> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
>> + ldr r1, =ftrace_graph_return
>> + ldr r2, [r1]
>> + cmp r0, r2 @ if *ftrace_graph_return != ftrace_stub
>> + bne new_ftrace_graph_caller
>> +#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
>> +
>> ldmia sp!, {r0-r3, ip, lr}
>> bx ip
>>
>> @@ -155,6 +163,18 @@ gnu_trace:
>> mov pc, r2
>> ldmia sp!, {r0-r3, ip, lr}
>> bx ip
>> +
>> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
>> +ENTRY(new_ftrace_graph_caller) @ for use with __gnu_mcount_nc
>> + sub r0, fp, #4 @ &lr of instrumented routine
>> (&parent)
>> + mov r1, lr @ instrumented routine (func)
>> + sub r1, r1, #MCOUNT_INSN_SIZE
>> + mov r2, fp @ frame pointer
>> + bl prepare_ftrace_return
>> + ldmia sp!, {r0-r3, ip, lr} @ need to pop lr, pushed before
>> + mov pc, ip @ bl __gnu_mcount_nc
>> +
>> +#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
>>
>> ENTRY(mcount)
>> stmdb sp!, {r0-r3, lr}
>>
>
> Wow, interesting timing. I just finished yesterday my own
> version of this patch (for 2.6.29) - it looks amazingingly similar.
>
> What's up with putting fp in r2 - is that required in the latest
> prepare_ftrace_return()?
> -- Tim
>
:D
I had to wait for legal clearance ;)
mov r2, fp is there in your patches on
http://elinux.org/Ftrace_Function_Graph_ARM. I'm using this for 2.6.31.
It seemed fishy to me as well, since you don't really change the fp, so
it should remain intact when control returns to the epilogue of the
instrumented function.
> ------------- patch follows ----------------
> Add support to __gnu_mcount_nc, used by newer (4.x?) Gnu compilers,
> for ftrace function_graph support on ARM.
>
> Signed-off-by: Tim Bird <tim.bird@am.sony.com>
> ---
> arch/arm/kernel/entry-common.S | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> --- a/arch/arm/kernel/entry-common.S
> +++ b/arch/arm/kernel/entry-common.S
> @@ -140,6 +140,12 @@ ENTRY(__gnu_mcount_nc)
> adr r0, ftrace_stub
> cmp r0, r2
> bne gnu_trace
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> + ldr r1, =ftrace_graph_return
> + ldr r2, [r1]
> + cmp r0, r2 @ if *ftrace_graph_return != ftrace_stub
> + bne gnu_ftrace_graph_caller
> +#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
> ldmia sp!, {r0-r3, ip, lr}
> bx ip
>
> @@ -196,6 +202,13 @@ return_to_handler:
> ldmia sp!, {r0-r3}
> mov pc, lr
>
> +ENTRY(gnu_ftrace_graph_caller)
> + sub r0, fp, #4 @ &lr of instrumented routine (&parent)
> + sub r1, lr, #MCOUNT_INSN_SIZE @ instrumented routine (func)
> + bl prepare_ftrace_return
> + ldmia sp!, {r0-r3, ip, lr}
> + bx ip
> +
> #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
>
> #endif /* CONFIG_DYNAMIC_FTRACE */
>
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-03-19 22:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-19 21:43 [PATCH] Make Function Duration Tracer work with __gnu_mcount_nc Ashwin Chaugule
2010-03-19 21:53 ` Tim Bird
2010-03-19 22:03 ` Ashwin Chaugule
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).