lkml.org 
[lkml]   [2009]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Anyone working on ftrace function graph support on ARM?

On Tue, 24 Mar 2009, Frederic Weisbecker wrote:

> On Tue, Mar 24, 2009 at 10:48:46PM +0100, Ingo Molnar wrote:
> >
> > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> >
> > > Well it's a very naive listing, there are sometimes some problems.
> > > For example on x86-64, I had to save even some non-scratch
> > > registers before calling the return hook, I still don't know why.
> >
> > btw., which are those registers?
> >
> > Ingo
>
>
> I would expect to only save rax,rdi,rsi,rdx,rcx,r8,r9 which
> are used for parameters.
> And I had some crashes until I append r10 and r11 which actually are
> scratch if I'm not wrong, but since they are scratch and are not used for
> arguments, I thought they didn't need to be saved.
>
> Well, I think there were some code flow cases I was missing.
>
>
> The complete code is:
>
> movq %rax, (%rsp)
> movq %rcx, 8(%rsp)
> movq %rdx, 16(%rsp)
> movq %rsi, 24(%rsp)
> movq %rdi, 32(%rsp)
> movq %r8, 40(%rsp)
> movq %r9, 48(%rsp)
> movq %r10, 56(%rsp)
> movq %r11, 64(%rsp)
>
> call ftrace_return_to_handler
>
> movq %rax, 72(%rsp) <-- get original return value
> movq 64(%rsp), %r11
> movq 56(%rsp), %r10
> movq 48(%rsp), %r9
> movq 40(%rsp), %r8
> movq 32(%rsp), %rdi
> movq 24(%rsp), %rsi
> movq 16(%rsp), %rdx
> movq 8(%rsp), %rcx
> movq (%rsp), %rax
> addq $72, %rsp

This bothers me. In PowerPC 64, all I have is:

_GLOBAL(return_to_handler)
/* need to save return values */
std r4, -24(r1)
std r3, -16(r1)
std r31, -8(r1)
mr r31, r1
stdu r1, -112(r1)

bl .ftrace_return_to_handler
nop

/* return value has real return address */
mtlr r3

ld r1, 0(r1)
ld r4, -24(r1)
ld r3, -16(r1)
ld r31, -8(r1)

/* Jump back to real return address */
blr

All I save is the return values (and I'm paranoid with that, by saving
both r3 and r4 and not just r3) as well as saving the stack. There should
be no reason to save any other registers.

This is not the same as mcount. mcount varies differently from arch to
arch. But this is the return of a function. This is not a mcount call, and
really has nothing to do with mcount.

If you think about it, the return is coming back from a function that
should have already saved all the registers that it modifies. The caller
of that function (the one we will return to) should have saved any
registers that are allowed to be modified by the callee.

When we call our ftrace_return_to_handler function it too will save any
register that it must for callees and restore it on return.

Perhaps the issue you had with x86_64 was that you did not set up the
stack frame properly? And by saving all those registers, it just happen to
do it for you?

-- Steve



\
 
 \ /
  Last update: 2009-03-25 17:03    [W:0.140 / U:0.404 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site