Re: Ftrace: Static function graph not work
From: Steven Rostedt
Date: Fri Mar 31 2017 - 09:49:44 EST
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) <rostedt@xxxxxxxxxxx>
> 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) <rostedt@xxxxxxxxxxx>
> 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