Messages in this thread | | | Date | Wed, 25 Mar 2009 12:00:24 -0400 (EDT) | From | Steven Rostedt <> | Subject | Re: 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
| |