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: Mike Frysinger <vapier@gentoo.org>
LKML-Reference: <1264165967-18938-1-git-send-email-vapier@gentoo.org>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
This commit is contained in:
Mike Frysinger 2010-01-22 08:12:47 -05:00 committed by Steven Rostedt
parent 6993b1bb1e
commit 0368897034
2 changed files with 24 additions and 6 deletions

View file

@ -1,5 +1,6 @@
function tracer guts function tracer guts
==================== ====================
By Mike Frysinger
Introduction Introduction
------------ ------------
@ -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)
#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
--------------------- ---------------------

View file

@ -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