123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382 |
- function tracer guts
- ====================
- By Mike Frysinger
- Introduction
- ------------
- Here we will cover the architecture pieces that the common function tracing
- code relies on for proper functioning. Things are broken down into increasing
- complexity so that you can start simple and at least get basic functionality.
- Note that this focuses on architecture implementation details only. If you
- want more explanation of a feature in terms of common code, review the common
- ftrace.txt file.
- Ideally, everyone who wishes to retain performance while supporting tracing in
- their kernel should make it all the way to dynamic ftrace support.
- Prerequisites
- -------------
- Ftrace relies on these features being implemented:
- STACKTRACE_SUPPORT - implement save_stack_trace()
- TRACE_IRQFLAGS_SUPPORT - implement include/asm/irqflags.h
- HAVE_FUNCTION_TRACER
- --------------------
- You will need to implement the mcount and the ftrace_stub functions.
- The exact mcount symbol name will depend on your toolchain. Some call it
- "mcount", "_mcount", or even "__mcount". You can probably figure it out by
- running something like:
- $ echo 'main(){}' | gcc -x c -S -o - - -pg | grep mcount
- call mcount
- We'll make the assumption below that the symbol is "mcount" just to keep things
- nice and simple in the examples.
- Keep in mind that the ABI that is in effect inside of the mcount function is
- *highly* architecture/toolchain specific. We cannot help you in this regard,
- sorry. Dig up some old documentation and/or find someone more familiar than
- you to bang ideas off of. Typically, register usage (argument/scratch/etc...)
- is a major issue at this point, especially in relation to the location of the
- mcount call (before/after function prologue). You might also want to look at
- how glibc has implemented the mcount function for your architecture. It might
- be (semi-)relevant.
- The mcount function should check the function pointer ftrace_trace_function
- to see if it is set to ftrace_stub. If it is, there is nothing for you to do,
- so return immediately. If it isn't, then call that function in the same way
- the mcount function normally calls __mcount_internal -- the first argument is
- the "frompc" while the second argument is the "selfpc" (adjusted to remove the
- size of the mcount call that is embedded in the function).
- For example, if the function foo() calls bar(), when the bar() function calls
- mcount(), the arguments mcount() will pass to the tracer are:
- "frompc" - the address bar() will use to return to foo()
- "selfpc" - the address bar() (with mcount() size adjustment)
- Also keep in mind that this mcount function will be called *a lot*, so
- optimizing for the default case of no tracer will help the smooth running of
- your system when tracing is disabled. So the start of the mcount function is
- typically the bare minimum with checking things before returning. That also
- means the code flow should usually be kept linear (i.e. no branching in the nop
- case). This is of course an optimization and not a hard requirement.
- Here is some pseudo code that should help (these functions should actually be
- implemented in assembly):
- void ftrace_stub(void)
- {
- return;
- }
- void mcount(void)
- {
- /* save any bare state needed in order to do initial checking */
- extern void (*ftrace_trace_function)(unsigned long, unsigned long);
- if (ftrace_trace_function != ftrace_stub)
- goto do_trace;
- /* restore any bare state */
- return;
- do_trace:
- /* save all state needed by the ABI (see paragraph above) */
- unsigned long frompc = ...;
- unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE;
- ftrace_trace_function(frompc, selfpc);
- /* restore all state needed by the ABI */
- }
- Don't forget to export mcount for modules !
- extern void mcount(void);
- EXPORT_SYMBOL(mcount);
- HAVE_FUNCTION_GRAPH_TRACER
- --------------------------
- Deep breath ... time to do some real work. Here you will need to update the
- mcount function to check ftrace graph function pointers, as well as implement
- some functions to save (hijack) and restore the return address.
- The mcount function should check the function pointers ftrace_graph_return
- (compare to ftrace_stub) and ftrace_graph_entry (compare to
- ftrace_graph_entry_stub). If either of those is not set to the relevant stub
- function, call the arch-specific function ftrace_graph_caller which in turn
- calls the arch-specific function prepare_ftrace_return. Neither of these
- function names is strictly required, but you should use them anyway to stay
- consistent across the architecture ports -- easier to compare & contrast
- things.
- The arguments to prepare_ftrace_return are slightly different than what are
- passed to ftrace_trace_function. The second argument "selfpc" is the same,
- but the first argument should be a pointer to the "frompc". Typically this is
- located on the stack. This allows the function to hijack the return address
- temporarily to have it point to the arch-specific function return_to_handler.
- That function will simply call the common ftrace_return_to_handler function and
- that will return the original return address with which you can return to the
- original call site.
- Here is the updated mcount pseudo code:
- void mcount(void)
- {
- ...
- if (ftrace_trace_function != ftrace_stub)
- goto do_trace;
- +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
- + extern void (*ftrace_graph_return)(...);
- + extern void (*ftrace_graph_entry)(...);
- + if (ftrace_graph_return != ftrace_stub ||
- + ftrace_graph_entry != ftrace_graph_entry_stub)
- + ftrace_graph_caller();
- +#endif
- /* restore any bare state */
- ...
- Here is the pseudo code for the new ftrace_graph_caller assembly function:
- #ifdef CONFIG_FUNCTION_GRAPH_TRACER
- void ftrace_graph_caller(void)
- {
- /* save all state needed by the ABI */
- unsigned long *frompc = &...;
- unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE;
- /* passing frame pointer up is optional -- see below */
- prepare_ftrace_return(frompc, selfpc, frame_pointer);
- /* restore all state needed by the ABI */
- }
- #endif
- For information on how to implement prepare_ftrace_return(), simply look at the
- 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
- across architectures.
- Here is the pseudo code for the new return_to_handler assembly function. Note
- that the ABI that applies here is different from what applies to the mcount
- code. Since you are returning from a function (after the epilogue), you might
- be able to skimp on things saved/restored (usually just registers used to pass
- return values).
- #ifdef CONFIG_FUNCTION_GRAPH_TRACER
- void return_to_handler(void)
- {
- /* save all state needed by the ABI (see paragraph above) */
- void (*original_return_point)(void) = ftrace_return_to_handler();
- /* restore all state needed by the ABI */
- /* this is usually either a return or a jump */
- original_return_point();
- }
- #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 optimization 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
- ---------------------
- If you can't trace NMI functions, then skip this option.
- <details to be filled>
- HAVE_SYSCALL_TRACEPOINTS
- ------------------------
- You need very few things to get the syscalls tracing in an arch.
- - Support HAVE_ARCH_TRACEHOOK (see arch/Kconfig).
- - Have a NR_syscalls variable in <asm/unistd.h> that provides the number
- of syscalls supported by the arch.
- - Support the TIF_SYSCALL_TRACEPOINT thread flags.
- - Put the trace_sys_enter() and trace_sys_exit() tracepoints calls from ptrace
- in the ptrace syscalls tracing path.
- - If the system call table on this arch is more complicated than a simple array
- of addresses of the system calls, implement an arch_syscall_addr to return
- the address of a given system call.
- - If the symbol names of the system calls do not match the function names on
- this arch, define ARCH_HAS_SYSCALL_MATCH_SYM_NAME in asm/ftrace.h and
- implement arch_syscall_match_sym_name with the appropriate logic to return
- true if the function name corresponds with the symbol name.
- - Tag this arch as HAVE_SYSCALL_TRACEPOINTS.
- HAVE_FTRACE_MCOUNT_RECORD
- -------------------------
- See scripts/recordmcount.pl for more info. Just fill in the arch-specific
- details for how to locate the addresses of mcount call sites via objdump.
- This option doesn't make much sense without also implementing dynamic ftrace.
- HAVE_DYNAMIC_FTRACE
- -------------------
- You will first need HAVE_FTRACE_MCOUNT_RECORD and HAVE_FUNCTION_TRACER, so
- scroll your reader back up if you got over eager.
- Once those are out of the way, you will need to implement:
- - asm/ftrace.h:
- - MCOUNT_ADDR
- - ftrace_call_adjust()
- - struct dyn_arch_ftrace{}
- - asm code:
- - mcount() (new stub)
- - ftrace_caller()
- - ftrace_call()
- - ftrace_stub()
- - C code:
- - ftrace_dyn_arch_init()
- - ftrace_make_nop()
- - ftrace_make_call()
- - ftrace_update_ftrace_func()
- First you will need to fill out some arch details in your asm/ftrace.h.
- Define MCOUNT_ADDR as the address of your mcount symbol similar to:
- #define MCOUNT_ADDR ((unsigned long)mcount)
- Since no one else will have a decl for that function, you will need to:
- extern void mcount(void);
- You will also need the helper function ftrace_call_adjust(). Most people
- will be able to stub it out like so:
- static inline unsigned long ftrace_call_adjust(unsigned long addr)
- {
- return addr;
- }
- <details to be filled>
- Lastly you will need the custom dyn_arch_ftrace structure. If you need
- some extra state when runtime patching arbitrary call sites, this is the
- place. For now though, create an empty struct:
- struct dyn_arch_ftrace {
- /* No extra data needed */
- };
- With the header out of the way, we can fill out the assembly code. While we
- did already create a mcount() function earlier, dynamic ftrace only wants a
- stub function. This is because the mcount() will only be used during boot
- and then all references to it will be patched out never to return. Instead,
- the guts of the old mcount() will be used to create a new ftrace_caller()
- function. Because the two are hard to merge, it will most likely be a lot
- easier to have two separate definitions split up by #ifdefs. Same goes for
- the ftrace_stub() as that will now be inlined in ftrace_caller().
- Before we get confused anymore, let's check out some pseudo code so you can
- implement your own stuff in assembly:
- void mcount(void)
- {
- return;
- }
- void ftrace_caller(void)
- {
- /* save all state needed by the ABI (see paragraph above) */
- unsigned long frompc = ...;
- unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE;
- ftrace_call:
- ftrace_stub(frompc, selfpc);
- /* restore all state needed by the ABI */
- ftrace_stub:
- return;
- }
- This might look a little odd at first, but keep in mind that we will be runtime
- patching multiple things. First, only functions that we actually want to trace
- will be patched to call ftrace_caller(). Second, since we only have one tracer
- active at a time, we will patch the ftrace_caller() function itself to call the
- specific tracer in question. That is the point of the ftrace_call label.
- With that in mind, let's move on to the C code that will actually be doing the
- runtime patching. You'll need a little knowledge of your arch's opcodes in
- order to make it through the next section.
- Every arch has an init callback function. If you need to do something early on
- to initialize some state, this is the time to do that. Otherwise, this simple
- function below should be sufficient for most people:
- int __init ftrace_dyn_arch_init(void)
- {
- return 0;
- }
- There are two functions that are used to do runtime patching of arbitrary
- functions. The first is used to turn the mcount call site into a nop (which
- is what helps us retain runtime performance when not tracing). The second is
- used to turn the mcount call site into a call to an arbitrary location (but
- typically that is ftracer_caller()). See the general function definition in
- linux/ftrace.h for the functions:
- ftrace_make_nop()
- ftrace_make_call()
- The rec->ip value is the address of the mcount call site that was collected
- by the scripts/recordmcount.pl during build time.
- The last function is used to do runtime patching of the active tracer. This
- will be modifying the assembly code at the location of the ftrace_call symbol
- inside of the ftrace_caller() function. So you should have sufficient padding
- at that location to support the new function calls you'll be inserting. Some
- people will be using a "call" type instruction while others will be using a
- "branch" type instruction. Specifically, the function is:
- ftrace_update_ftrace_func()
- HAVE_DYNAMIC_FTRACE + HAVE_FUNCTION_GRAPH_TRACER
- ------------------------------------------------
- The function grapher needs a few tweaks in order to work with dynamic ftrace.
- Basically, you will need to:
- - update:
- - ftrace_caller()
- - ftrace_graph_call()
- - ftrace_graph_caller()
- - implement:
- - ftrace_enable_ftrace_graph_caller()
- - ftrace_disable_ftrace_graph_caller()
- <details to be filled>
- Quick notes:
- - add a nop stub after the ftrace_call location named ftrace_graph_call;
- stub needs to be large enough to support a call to ftrace_graph_caller()
- - update ftrace_graph_caller() to work with being called by the new
- ftrace_caller() since some semantics may have changed
- - ftrace_enable_ftrace_graph_caller() will runtime patch the
- ftrace_graph_call location with a call to ftrace_graph_caller()
- - ftrace_disable_ftrace_graph_caller() will runtime patch the
- ftrace_graph_call location with nops
|