* [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).