Hi all,
I test the static function graph for ARM, x86 and x86_64 architecture
on linux-3.10 and linux-4.9, and I find it works correctly only for
x86_64 on linux-4.9.
After the following commit, the function tracer also be registered
when registering the function graph tracer.
commit 2940c25bec92f40a3f7f32504b8ea115d1701892
Author: Steven Rostedt (Red Hat) <[email protected]>
CommitDate: Wed Dec 4 10:57:05 2013 -0800
ftrace: Fix function graph with loading of modules
The arch-depend code implement the mcount function pseudo code like:
void mcount(void)
{
...
if (ftrace_trace_function != ftrace_stub)
goto do_trace;
#ifdef CONFIG_FUNCTION_GRAPH_TRACER
if (ftrace_graph_return != ftrace_stub ||
ftrace_graph_entry != ftrace_graph_entry_stub)
ftrace_graph_caller();
#endif
return;
do_trace:
...
}
The function pointer 'ftrace_trace_function' will not be 'ftrace_stub'
because function tracer is registered too, so the function graph part
will not be executed.
On the other hand, I find the another patch to resolve this situation,
and it is reason that x86_64 architecture can work correctly.
commit 62a207d748dd9224140a634786b274fdb6ece0b9
Author: Steven Rostedt (Red Hat) <[email protected]>
CommitDate: Mon Nov 24 15:02:25 2014 -0500
ftrace/x86: Have static function tracing always test for function graph
so, is this problem tending to handle by each architecture? or maybe
it is need to solve by generic code?
This is my first mail to mailing list, please excuse having mistake
and let me know.
Thank a lot !
ping
2017-03-23 11:28 GMT+08:00 Zong Li <[email protected]>:
> Hi all,
>
> I test the static function graph for ARM, x86 and x86_64 architecture
> on linux-3.10 and linux-4.9, and I find it works correctly only for
> x86_64 on linux-4.9.
>
> After the following commit, the function tracer also be registered
> when registering the function graph tracer.
>
> commit 2940c25bec92f40a3f7f32504b8ea115d1701892
> Author: Steven Rostedt (Red Hat) <[email protected]>
> CommitDate: Wed Dec 4 10:57:05 2013 -0800
>
> ftrace: Fix function graph with loading of modules
>
>
> The arch-depend code implement the mcount function pseudo code like:
>
> void mcount(void)
> {
> ...
> if (ftrace_trace_function != ftrace_stub)
> goto do_trace;
>
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> if (ftrace_graph_return != ftrace_stub ||
> ftrace_graph_entry != ftrace_graph_entry_stub)
> ftrace_graph_caller();
> #endif
> return;
>
> do_trace:
> ...
> }
>
> The function pointer 'ftrace_trace_function' will not be 'ftrace_stub'
> because function tracer is registered too, so the function graph part
> will not be executed.
>
>
> On the other hand, I find the another patch to resolve this situation,
> and it is reason that x86_64 architecture can work correctly.
>
> commit 62a207d748dd9224140a634786b274fdb6ece0b9
> Author: Steven Rostedt (Red Hat) <[email protected]>
> CommitDate: Mon Nov 24 15:02:25 2014 -0500
>
> ftrace/x86: Have static function tracing always test for function graph
>
>
> so, is this problem tending to handle by each architecture? or maybe
> it is need to solve by generic code?
>
>
> This is my first mail to mailing list, please excuse having mistake
> and let me know.
> Thank a lot !
On Thu, Mar 23, 2017 at 11:28:03AM +0800, Zong Li wrote:
> Hi all,
>
> I test the static function graph for ARM, x86 and x86_64 architecture
> on linux-3.10 and linux-4.9, and I find it works correctly only for
> x86_64 on linux-4.9.
I'm curious. Are you just testing these to run normal QA, or do you actually
have a need for static function graph tracing? Reason why I ask, is that we
are thinking about removing it completely, because dynamic function tracing is
the only one that really makes sense. I only keep it around on x86 because
static function tracing is easy to implement on other archs, and I like to
still test it on x86. But that reason is getting weaker.
>
> After the following commit, the function tracer also be registered
> when registering the function graph tracer.
>
> commit 2940c25bec92f40a3f7f32504b8ea115d1701892
> Author: Steven Rostedt (Red Hat) <[email protected]>
> CommitDate: Wed Dec 4 10:57:05 2013 -0800
>
> ftrace: Fix function graph with loading of modules
>
>
> The arch-depend code implement the mcount function pseudo code like:
>
> void mcount(void)
> {
> ...
> if (ftrace_trace_function != ftrace_stub)
> goto do_trace;
>
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> if (ftrace_graph_return != ftrace_stub ||
> ftrace_graph_entry != ftrace_graph_entry_stub)
> ftrace_graph_caller();
> #endif
> return;
>
> do_trace:
> ...
> }
>
> The function pointer 'ftrace_trace_function' will not be 'ftrace_stub'
> because function tracer is registered too, so the function graph part
> will not be executed.
>
>
> On the other hand, I find the another patch to resolve this situation,
> and it is reason that x86_64 architecture can work correctly.
>
> commit 62a207d748dd9224140a634786b274fdb6ece0b9
> Author: Steven Rostedt (Red Hat) <[email protected]>
> CommitDate: Mon Nov 24 15:02:25 2014 -0500
>
> ftrace/x86: Have static function tracing always test for function graph
>
>
> so, is this problem tending to handle by each architecture? or maybe
> it is need to solve by generic code?
Well, it's written in assembly, so having it be generic code is out of the
question. But I should fix this for x86_32 if that's broken there. Other archs
are on their own.
>
>
> This is my first mail to mailing list, please excuse having mistake
> and let me know.
I noticed this email because you sent a "ping" with me Cc'd. Just to let you
know, this mailing list gets over 600 emails a *day*! Nobody reads all of it.
For future reference, always Cc those that you want to read your email when
sending to the list, otherwise it will get lost in the flood.
-- Steve
2017-03-31 21:42 GMT+08:00 Steven Rostedt <[email protected]>:
> On Thu, Mar 23, 2017 at 11:28:03AM +0800, Zong Li wrote:
>> Hi all,
>>
>> I test the static function graph for ARM, x86 and x86_64 architecture
>> on linux-3.10 and linux-4.9, and I find it works correctly only for
>> x86_64 on linux-4.9.
>
> I'm curious. Are you just testing these to run normal QA, or do you actually
> have a need for static function graph tracing? Reason why I ask, is that we
> are thinking about removing it completely, because dynamic function tracing is
> the only one that really makes sense. I only keep it around on x86 because
> static function tracing is easy to implement on other archs, and I like to
> still test it on x86. But that reason is getting weaker.
It's exactly. I think the dynamic function tracing is really makes sense.
I find this problem because I'm porting the static and dynamic
function tracer for
the AndesCore architecture and we are planing to contribute our
architecture in the future.
I had implemented it on kernel-3.4 before, and it work fine,
so this is reason why I sent this mail for my confusion.
>> After the following commit, the function tracer also be registered
>> when registering the function graph tracer.
>>
>> commit 2940c25bec92f40a3f7f32504b8ea115d1701892
>> Author: Steven Rostedt (Red Hat) <[email protected]>
>> CommitDate: Wed Dec 4 10:57:05 2013 -0800
>>
>> ftrace: Fix function graph with loading of modules
>>
>>
>> The arch-depend code implement the mcount function pseudo code like:
>>
>> void mcount(void)
>> {
>> ...
>> if (ftrace_trace_function != ftrace_stub)
>> goto do_trace;
>>
>> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>> if (ftrace_graph_return != ftrace_stub ||
>> ftrace_graph_entry != ftrace_graph_entry_stub)
>> ftrace_graph_caller();
>> #endif
>> return;
>>
>> do_trace:
>> ...
>> }
>>
>> The function pointer 'ftrace_trace_function' will not be 'ftrace_stub'
>> because function tracer is registered too, so the function graph part
>> will not be executed.
>>
>>
>> On the other hand, I find the another patch to resolve this situation,
>> and it is reason that x86_64 architecture can work correctly.
>>
>> commit 62a207d748dd9224140a634786b274fdb6ece0b9
>> Author: Steven Rostedt (Red Hat) <[email protected]>
>> CommitDate: Mon Nov 24 15:02:25 2014 -0500
>>
>> ftrace/x86: Have static function tracing always test for function graph
>>
>>
>> so, is this problem tending to handle by each architecture? or maybe
>> it is need to solve by generic code?
>
> Well, it's written in assembly, so having it be generic code is out of the
> question. But I should fix this for x86_32 if that's broken there. Other archs
> are on their own.
Yes, I think it should be handle on architectures own and I'll fix it
on our arch.
>>
>>
>> This is my first mail to mailing list, please excuse having mistake
>> and let me know.
>
> I noticed this email because you sent a "ping" with me Cc'd. Just to let you
> know, this mailing list gets over 600 emails a *day*! Nobody reads all of it.
> For future reference, always Cc those that you want to read your email when
> sending to the list, otherwise it will get lost in the flood.
>
> -- Steve
I deeply appreciate your reply and notice. Thanks a lot!