From mboxrd@z Thu Jan 1 00:00:00 1970 From: catalin.marinas@arm.com (Catalin Marinas) Date: Thu, 22 Sep 2011 14:00:31 +0100 Subject: [PATCH] arm: Add unwinding annotations for 64bit division functions In-Reply-To: <1316693581.2053.38.camel@linaro1> References: <1316470297-5063-1-git-send-email-lauraa@codeaurora.org> <2285dff3fee56758b6279062a5a30dc7.squirrel@www.codeaurora.org> <20110921113906.GB2872@arm.com> <20110921115553.GF17169@n2100.arm.linux.org.uk> <1316676488.2053.9.camel@linaro1> <1316689606.2053.29.camel@linaro1> <20110922115713.GJ12025@e102109-lin.cambridge.arm.com> <1316693581.2053.38.camel@linaro1> Message-ID: <20110922130031.GK12025@e102109-lin.cambridge.arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Sep 22, 2011 at 01:13:01PM +0100, Jon Medhurst (Tixy) wrote: > On Thu, 2011-09-22 at 12:57 +0100, Catalin Marinas wrote: > > On Thu, Sep 22, 2011 at 12:06:46PM +0100, Jon Medhurst (Tixy) wrote: > > > On Thu, 2011-09-22 at 10:48 +0100, Catalin Marinas wrote: > > > > We could improve things a bit in the unwinder and assume > > > > that if the fault address is the same as the .fnstart address, the > > > > return value is always in LR and the SP not affected (that's unwinding > > > > bytecode 0xb0). For a few instructions into the function prologue we > > > > can't reliably get the unwinding information. > > > > > > That would help make it possible to unwind out of kprobes handlers to > > > the probed function. The kprobes code itself would need work as well, > > > and possibly the undef handler. Do we think it is worthwhile to do > > > this? > > > > Does kprobes need to trace beyond the probed function? If not, you get > > the address of the probed function via pt_regs anyway, so no need for > > unwinding beyond that. > > To be honest, I'm not very sure how kprobes get used in the real world. > Though, if stack unwinding from their handlers currently doesn't work > and people had a usecase for it, we would expect them to complain. The unwinding fix should be simple (I haven't tested it yet): 8<----------------------------- ARM: Ignore the unwinding information for the first instruction in a function From: Catalin Marinas When backtracing from the first instruction of a function, the prologue has not been executed and the unwinding information is not valid. This patch checks for this case and just assumes that the return address is in LR. Signed-off-by: Catalin Marinas --- arch/arm/kernel/unwind.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c index d2cb0b3..946face 100644 --- a/arch/arm/kernel/unwind.c +++ b/arch/arm/kernel/unwind.c @@ -293,6 +293,16 @@ int unwind_frame(struct stackframe *frame) return -URC_FAILURE; } + /* + * Check for backtrace on the first instruction of a function. The + * prologue has not been executed yet and the unwinding information is + * not valid. Assume that the return address is in LR. + */ + if (idx.addr == frame->pc) { + frame->pc = frame->lr; + return URC_OK; + } + ctrl.vrs[FP] = frame->fp; ctrl.vrs[SP] = frame->sp; ctrl.vrs[LR] = frame->lr; -- Catalin