[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.0903251724120.5675@gandalf.stny.rr.com>
Date: Wed, 25 Mar 2009 17:26:22 -0400 (EDT)
From: Steven Rostedt <rostedt@...dmis.org>
To: Jaswinder Singh Rajput <jaswinder@...nel.org>
cc: linux kernel <linux-kernel@...r.kernel.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...e.hu>, Tim Bird <tim.bird@...sony.com>,
Ingo Molnar <mingo@...hat.com>,
Abhishek Sagar <sagar.abhishek@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH][GIT PULL] x86, function-graph: only save return values
on x86_64
On Thu, 26 Mar 2009, Jaswinder Singh Rajput wrote:
> >
> > diff --git a/arch/x86/kernel/entry_64.S b/arch/x86/kernel/entry_64.S
> > index a331ec3..1ac9986 100644
> > --- a/arch/x86/kernel/entry_64.S
> > +++ b/arch/x86/kernel/entry_64.S
> > @@ -147,27 +147,14 @@ END(ftrace_graph_caller)
> > GLOBAL(return_to_handler)
> > subq $80, %rsp
> >
> > + /* Save the return values */
> > 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)
> > + movq %rdx, 8(%rsp)
> >
> > call ftrace_return_to_handler
> >
> > movq %rax, 72(%rsp)
> > - 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 8(%rsp), %rdx
> > movq (%rsp), %rax
> > addq $72, %rsp
> > retq
>
> hmm, is this gonna work:
> movq %rax, 16(%rsp)
> movq 8(%rsp), %rdx
> movq (%rsp), %rax
> addq $16, %rsp
> retq
Interesting. I was just talking over IRC with Frederic about this. One
theory about his earlier failures was not having a proper stack frame when
calling the function. This is probably a bogus theory and there was
probably something else that broke the code. But there is no harm in
allocating 80 bytes (it worked before). Thus, I rather error on the side
of least change than risk it.
-- 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