Lines Matching refs:to
16 Ideally, everyone who wishes to retain performance while supporting tracing in
17 their kernel should make it all the way to dynamic ftrace support.
31 You will need to implement the mcount and the ftrace_stub functions.
38 We'll make the assumption below that the symbol is "mcount" just to keep things
44 you to bang ideas off of. Typically, register usage (argument/scratch/etc...)
45 is a major issue at this point, especially in relation to the location of the
46 mcount call (before/after function prologue). You might also want to look at
51 to see if it is set to ftrace_stub. If it is, there is nothing for you to do,
54 the "frompc" while the second argument is the "selfpc" (adjusted to remove the
58 mcount(), the arguments mcount() will pass to the tracer are:
59 "frompc" - the address bar() will use to return to foo()
79 /* save any bare state needed in order to do initial checking */
100 Don't forget to export mcount for modules !
108 Deep breath ... time to do some real work. Here you will need to update the
109 mcount function to check ftrace graph function pointers, as well as implement
110 some functions to save (hijack) and restore the return address.
113 (compare to ftrace_stub) and ftrace_graph_entry (compare to
114 ftrace_graph_entry_stub). If either of those is not set to the relevant stub
117 function names is strictly required, but you should use them anyway to stay
118 consistent across the architecture ports -- easier to compare & contrast
121 The arguments to prepare_ftrace_return are slightly different than what are
122 passed to ftrace_trace_function. The second argument "selfpc" is the same,
123 but the first argument should be a pointer to the "frompc". Typically this is
124 located on the stack. This allows the function to hijack the return address
125 temporarily to have it point to the arch-specific function return_to_handler.
127 that will return the original return address with which you can return to the
163 For information on how to implement prepare_ftrace_return(), simply look at the
170 that the ABI that applies here is different from what applies to the mcount
172 be able to skimp on things saved/restored (usually just registers used to pass
193 An arch may pass in a unique value (frame pointer) to both the entering and
202 along to ftrace_push_return_trace() instead of a stub value of 0.
212 <details to be filled>
218 You need very few things to get the syscalls tracing in an arch.
227 of addresses of the system calls, implement an arch_syscall_addr to return
231 implement arch_syscall_match_sym_name with the appropriate logic to return
240 details for how to locate the addresses of mcount call sites via objdump.
250 Once those are out of the way, you will need to implement:
266 First you will need to fill out some arch details in your asm/ftrace.h.
268 Define MCOUNT_ADDR as the address of your mcount symbol similar to:
270 Since no one else will have a decl for that function, you will need to:
274 will be able to stub it out like so:
279 <details to be filled>
291 and then all references to it will be patched out never to return. Instead,
292 the guts of the old mcount() will be used to create a new ftrace_caller()
293 function. Because the two are hard to merge, it will most likely be a lot
294 easier to have two separate definitions split up by #ifdefs. Same goes for
322 patching multiple things. First, only functions that we actually want to trace
323 will be patched to call ftrace_caller(). Second, since we only have one tracer
324 active at a time, we will patch the ftrace_caller() function itself to call the
327 With that in mind, let's move on to the C code that will actually be doing the
329 order to make it through the next section.
331 Every arch has an init callback function. If you need to do something early on
332 to initialize some state, this is the time to do that. Otherwise, this simple
340 There are two functions that are used to do runtime patching of arbitrary
341 functions. The first is used to turn the mcount call site into a nop (which
343 used to turn the mcount call site into a call to an arbitrary location (but
351 The last function is used to do runtime patching of the active tracer. This
354 at that location to support the new function calls you'll be inserting. Some
363 The function grapher needs a few tweaks in order to work with dynamic ftrace.
364 Basically, you will need to:
373 <details to be filled>
376 stub needs to be large enough to support a call to ftrace_graph_caller()
377 - update ftrace_graph_caller() to work with being called by the new
380 ftrace_graph_call location with a call to ftrace_graph_caller()