[lkml]   [2009]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 2/2 v2] ftrace: document basic ftracer/ftracer graph needs
    On Sun, Jun 14, 2009 at 11:10, Wu Zhangjin wrote:
    > On Wed, 2009-06-10 at 16:52 -0400, Mike Frysinger wrote:
    >> +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.
    >> ...
    >> +void ftrace_graph_caller(void)
    >> +{
    >> +     /* save all state needed by the ABI */
    >> +
    >> +     unsigned long *frompc = &...;
    >> +     unsigned long selfpc = <return address> - MCOUNT_INSN_SIZE;
    >> +     prepare_ftrace_return(frompc, selfpc);
    >> +
    >> +     /* restore all state needed by the ABI */
    >> +}
    >> +#endif
    >> +
    >> +For information on how to implement prepare_ftrace_return(), simply look at
    >> +the x86 version.  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.
    >> +
    > and the fault recovery table is not needed.

    i dont have one for the Blackfin port, but that's more because there
    is no fault recovery support in the Blackfin port ;)

    > In reality, the prepare_ftrace_return() can have the same arguments as
    > ftrace_trace_function()
    > ...
    > as i know, prepare_ftrace_return() is used to check whether the calling
    > function expect to trace, if yes, return the 'hook' function
    > &return_to_handler, otherwise, return back to the parent_ip directly.
    > so, here, i think there is no need to transfer the data via address, but
    > just using the same arguments like ftrace_trace_function does.

    hmm, that would make the implementation simpler, but i dont think you
    could do that if you implemented the fault handler. i cant really
    speak as to the requirement of the fault handler as i dont really know
    what/how it works -- i can only guess at they arent used in any way
    for Blackfin systems.

    > unsigned long
    > prepare_ftrace_return(unsgined long ip, unsigned long parent_ip)
    > {
    >    [...]
    >    if (ftrace_push_return_trace(parent_ip, ip, &trace.depth) == -EBUSY)
    >        return parent_ip;
    >    if (ftrace_graph_entry(&trace))
    >        return (unsigned long)&return_to_handler;
    >    [...]
    >    return parent_ip;
    > }
    > if using the above method, the fault recovery table is not needed again.

    and it would allow us to move this code into the common ftrace
    framework for people who dont do fault handlers.

    > am i wrong? if this method is okay, so, this document should not only
    > refer to the x86's implementation detail, but focus on the basic
    > principle of prepare_ftrace_return().

    ppc also uses the same method as x86 which is why i wrote it that way.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-06-14 17:47    [W:0.031 / U:6.392 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site