Message-ID: <20090325171357.GB5932@nowhere>
Date:	Wed, 25 Mar 2009 18:13:59 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Tim Bird <tim.bird@...sony.com>,
	linux-arm-kernel <linux-arm-kernel@...ts.arm.linux.org.uk>,
	linux kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Abhishek Sagar <sagar.abhishek@...il.com>,
	Russell King <rmk@....linux.org.uk>,
	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
Subject: Re: Anyone working on ftrace function graph support on ARM?

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@...il.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
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists