lkml.org 
[lkml]   [2009]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ARM + jprobes/kretprobes SEGV/hangs/OOPS in 2.6.29 kernel
On Tue, 1 Sep 2009, Catalin Marinas wrote:

> On Tue, 2009-09-01 at 15:25 +0100, Russell King wrote:
> > On Tue, Sep 01, 2009 at 02:54:54PM +0100, Catalin Marinas wrote:
> > > venki kaps <venkiece2005@gmail.com> wrote:
> > > > I have found the exact problem with respect to ARM jprobes.
> > > >
> > > > The problem with configure i.e, CONFIG_ARM_UNWIND = y; is enabled.
> > >
> > > I haven't followed the kprobes implementation for ARM but does it make
> > > any assumptions about the existence of a frame pointer on the stack?
> > > Enabling stack unwinding automatically disables the framepointer.
> >
> > If it uses CALLER_ADDRESSx() then it won't work with unwinding enabled.
> > See 5613/1 (which is pending in the devel branch.)
>
> In addition to that, when CONFIG_FRAME_POINTER is disabled, the lr
> register isn't always saved on the stack by the called function. I'm not
> sure whether kretprobe_trampoline is aware of this.

The way a kretprobe works is to put a trap at the very first instruction
of the targetted function, preserve the value of LR when the trap is
hit, and substitute it with the address of kretprobe_trampoline. Then
the original first instruction is emulated to pass over the trap point
and normal execution is resumed. So whether or not LR is then saved on
the stack doesn't matter to kretprobe_trampoline as it will restore the
LR value saved during the initial trap.

Of course if you end up generating a backtrace within a kretprobed
function then the result might look funny.


Nicolas


\
 
 \ /
  Last update: 2009-09-01 19:59    [W:0.044 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site