Message-ID: <alpine.DEB.2.00.0903251153500.5675@gandalf.stny.rr.com>
Date:	Wed, 25 Mar 2009 12:00:24 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
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 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?

-- 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