[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.0911190934070.2793@localhost.localdomain>
Date:	Thu, 19 Nov 2009 09:39:21 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	feng.tang@...el.com, Fr??d??ric Weisbecker <fweisbec@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>, jakub@...hat.com,
	gcc@....gnu.org
Subject: Re: BUG: GCC-4.4.x changes the function frame on some functions
On Thu, 19 Nov 2009, Thomas Gleixner wrote:
> 
> standard function start:
> 
> 	 push	%ebp
> 	 mov	%esp, %ebp
> 	 ....
> 	 call   mcount
> 
> modified function start on a handful of functions only seen with gcc
> 4.4.x on x86 32 bit:
> 
> 	push   %edi
> 	lea    0x8(%esp),%edi
> 	and    $0xfffffff0,%esp
> 	pushl  -0x4(%edi)
> 	push   %ebp
> 	mov    %esp,%ebp
> 	...
> 	call   mcount
That's some crazy sh*t anyway, since we don't _want_ the stack to be 
16-byte aligned in the kernel. We do
        KBUILD_CFLAGS += $(call cc-option,-mpreferred-stack-boundary=2)
why is that not working?
So this looks like a gcc bug, plain and simple.
> This modification leads to a hard to solve problem in the kernel
> function graph tracer which assumes that the stack looks like:
> 
>        return address
>        saved  ebp
Umm. But it still does, doesn't it? That
	pushl  -0x4(%edi)
	push   %ebp
should do it - the "-0x4(%edi)" thing seems to be trying to reload the 
return address. No? 
Maybe I misread the code - but regardless, it does look like a gcc code 
generation bug if only because we really don't want a 16-byte aligned 
stack anyway, and have asked for it to not be done.
So I agree that gcc shouldn't do that crazy prologue (and certainly _not_ 
before calling mcount anyway), but I'm not sure I agree with that detail 
of your analysis or explanation.
				Linus
--
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
 
