[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090325085418.GA2341@elte.hu>
Date: Wed, 25 Mar 2009 09:54:18 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Russell King - ARM Linux <linux@....linux.org.uk>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
Abhishek Sagar <sagar.abhishek@...il.com>,
Tim Bird <tim.bird@...sony.com>,
linux-arm-kernel <linux-arm-kernel@...ts.arm.linux.org.uk>,
linux kernel <linux-kernel@...r.kernel.org>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...hat.com>,
Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
Subject: Re: Anyone working on ftrace function graph support on ARM?
* Russell King - ARM Linux <linux@....linux.org.uk> wrote:
> On Tue, Mar 24, 2009 at 11:48:58PM +0100, Frederic Weisbecker wrote:
> > On Tue, Mar 24, 2009 at 06:29:03PM -0400, Abhishek Sagar wrote:
> > > Instead of just restoring the old backed-up args, lr can be fixed up
> > > inside the entry hook to point to the return hook. So when the traced
> > > function returns, it actually returns to the return hook (where we can
> > > restore the original return address). This means that
> > > -finstrument-functions is not required at all. This is analogous to how
> > > kretprobes work. The only difference here is that instead of planting a
> > > kprobe at the function entry and redirecting the function return to the
> > > profiling exit routine, we can use mcount. This is slightly more
> > > complicated to implement but can be a very efficient alternative to
> > > kretprobes.
> > > --
> > > Abhishek
> > >
> >
> > Indeed, you need to override lr, that even the only solution.
> > I was still thinking in an x86 way with its on stack return address.
>
> As pointed out in my previous mail, identifying where on the stack
> the return address is stored is only possible for OABI with frame
> pointers.
>
> EABI will probably be possible with the stack unwinding code, but
> it probably won't be cheap. The EABI unwinder is scheduled for
> merging during the present now-open merge window.
Unwinding is not realistic or desired for the function tracer - it
runs in every kernel function so performance is paramount.
So, if i understood you correctly, an OABI_COMPAT and FRAME_POINTERS
dependency has to be added to the ARM HAVE_FUNCTION_GRAPH_TRACER
Kconfig rule.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists