Commit 03688970 authored by Mike Frysinger's avatar Mike Frysinger Committed by Steven Rostedt

tracing/documentation: Cover new frame pointer semantics

Update the graph tracer examples to cover the new frame pointer semantics
(in terms of passing it along).  Move the HAVE_FUNCTION_GRAPH_FP_TEST docs
out of the Kconfig, into the right place, and expand on the details.
Signed-off-by: default avatarMike Frysinger <vapier@gentoo.org>
LKML-Reference: <1264165967-18938-1-git-send-email-vapier@gentoo.org>
Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
parent 6993b1bb
function tracer guts function tracer guts
==================== ====================
By Mike Frysinger
Introduction Introduction
------------ ------------
...@@ -173,14 +174,16 @@ void ftrace_graph_caller(void) ...@@ -173,14 +174,16 @@ void ftrace_graph_caller(void)
unsigned long *frompc = &...; unsigned long *frompc = &...;
unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE; unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE;
prepare_ftrace_return(frompc, selfpc); /* passing frame pointer up is optional -- see below */
prepare_ftrace_return(frompc, selfpc, frame_pointer);
/* restore all state needed by the ABI */ /* restore all state needed by the ABI */
} }
#endif #endif
For information on how to implement prepare_ftrace_return(), simply look at For information on how to implement prepare_ftrace_return(), simply look at the
the x86 version. The only architecture-specific piece in it is the setup of x86 version (the frame pointer passing is optional; see the next section for
more information). The only architecture-specific piece in it is the setup of
the fault recovery table (the asm(...) code). The rest should be the same the fault recovery table (the asm(...) code). The rest should be the same
across architectures. across architectures.
...@@ -205,6 +208,23 @@ void return_to_handler(void) ...@@ -205,6 +208,23 @@ void return_to_handler(void)
#endif #endif
HAVE_FUNCTION_GRAPH_FP_TEST
---------------------------
An arch may pass in a unique value (frame pointer) to both the entering and
exiting of a function. On exit, the value is compared and if it does not
match, then it will panic the kernel. This is largely a sanity check for bad
code generation with gcc. If gcc for your port sanely updates the frame
pointer under different opitmization levels, then ignore this option.
However, adding support for it isn't terribly difficult. In your assembly code
that calls prepare_ftrace_return(), pass the frame pointer as the 3rd argument.
Then in the C version of that function, do what the x86 port does and pass it
along to ftrace_push_return_trace() instead of a stub value of 0.
Similarly, when you call ftrace_return_to_handler(), pass it the frame pointer.
HAVE_FTRACE_NMI_ENTER HAVE_FTRACE_NMI_ENTER
--------------------- ---------------------
......
...@@ -27,9 +27,7 @@ config HAVE_FUNCTION_GRAPH_TRACER ...@@ -27,9 +27,7 @@ config HAVE_FUNCTION_GRAPH_TRACER
config HAVE_FUNCTION_GRAPH_FP_TEST config HAVE_FUNCTION_GRAPH_FP_TEST
bool bool
help help
An arch may pass in a unique value (frame pointer) to both the See Documentation/trace/ftrace-design.txt
entering and exiting of a function. On exit, the value is compared
and if it does not match, then it will panic the kernel.
config HAVE_FUNCTION_TRACE_MCOUNT_TEST config HAVE_FUNCTION_TRACE_MCOUNT_TEST
bool bool
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment