Comments

Like x86, when the function graph tracer is enabled, emit the ftrace
stub as well as the program counter it will be transformed back into.
We duplicate a lot of similar stack walking logic in 3 or 4 spots, so
eventually we should consolidate things like x86 does.
Thanks to Frederic Weisbecker for pointing this out.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
arch/sparc/kernel/perf_event.c | 14 ++++++++++++++
arch/sparc/kernel/stacktrace.c | 23 ++++++++++++++++++++++-
arch/sparc/kernel/traps_64.c | 14 ++++++++++++++
3 files changed, 50 insertions(+), 1 deletions(-)

On Wed, Apr 21, 2010 at 03:23:55AM -0700, David Miller wrote:
> > Like x86, when the function graph tracer is enabled, emit the ftrace> stub as well as the program counter it will be transformed back into.> > We duplicate a lot of similar stack walking logic in 3 or 4 spots, so> eventually we should consolidate things like x86 does.
Yeah, in fact if we want a kind a arch agnostic graph stack walker,
we could make it an iterator.
(Modifying print_ftrace_graph_addr a bit)
static unsigned long
walk_ftrace_graph_stack(unsigned long addr,
struct task_struct *task, int *idx)
{
unsigned long ret_addr;
int index = task->curr_ret_stack;
if (addr != (unsigned long)return_to_handler)
return -ENOENT;
if (!task->ret_stack || index < *idx)
return -ENOENT;
index -= *idx;
ret_addr = task->ret_stack[index].ret;
(*idx)++;
return ret_addr;
}
Hmm?
I can make it in tracing/core but I fear it won't be available
for the sparc tree until .35
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html