Thread (15 messages) flat view 15 messages, 6 authors, 2011-09-22

[PATCH] arm: Add unwinding annotations for 64bit division functions

From: Jon Medhurst Tixy <hidden>
Date: 2011-09-22 11:06:57
Also in: linux-arm-msm, lkml

On Thu, 2011-09-22 at 10:48 +0100, Catalin Marinas wrote:
On 22 September 2011 08:28, Jon Medhurst (Tixy) [off-list ref] wrote:
quoted
On Wed, 2011-09-21 at 12:55 +0100, Russell King - ARM Linux wrote:
quoted
Instructions such as VFP, kprobes tracing, etc are expected fault
locations, and those are fairly well controlled where they can be placed.
With things like ftrace, it certainly is the case that the unwinder can
theoretically be called from almost anywhere in a function.
Actually, kprobes can be places on any instruction in the kernel that
isn't in the section .kprobes.text.

I also strongly suspect that stack unwinding won't happen correctly
across the boundary between the kprobes handling code and the function
which was probed - there's an awful lot of stack jiggery pokery going on
there.
Are people most likely to place kprobes on the first instruction of a
function? 
I believe that is the usual case.
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? 

-- 
Tixy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help