Re: Anyone working on ftrace function graph support on ARM?

Frederic Weisbecker
2009-03-25T17:14:19Z

On Wed, Mar 25, 2009 at 12:00:24PM -0400, Steven Rostedt wrote:
>
> 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?

I don't know. It seems to me that the stack frame is well set.
This is weird.

> -- Steve
>