Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754092AbZKSSlS (ORCPT ); Thu, 19 Nov 2009 13:41:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753339AbZKSSlR (ORCPT ); Thu, 19 Nov 2009 13:41:17 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:52160 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753086AbZKSSlQ (ORCPT ); Thu, 19 Nov 2009 13:41:16 -0500 Date: Thu, 19 Nov 2009 10:38:59 -0800 (PST) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Richard Guenther cc: rostedt@goodmis.org, Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , LKML , Andrew Morton , Heiko Carstens , feng.tang@intel.com, Fr??d??ric Weisbecker , Peter Zijlstra , jakub@redhat.com, gcc@gcc.gnu.org Subject: Re: BUG: GCC-4.4.x changes the function frame on some functions In-Reply-To: <84fc9c000911191003t244eb864o3d5b355ab5485f@mail.gmail.com> Message-ID: References: <20091119072040.GA23579@elte.hu> <1258653562.22249.682.camel@gandalf.stny.rr.com> <84fc9c000911191003t244eb864o3d5b355ab5485f@mail.gmail.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2889 Lines: 77 On Thu, 19 Nov 2009, Richard Guenther wrote: > > Note that I only can reproduce the issue with > -mincoming-stack-boundary=2, not with -mpreferred-stack-boundary=2. Since you can reproduce it with -mincoming-stack-boundary=2, I woul suggest just fixing mcount handling that way regardless of anything else. The current code generated by gcc is just insane - even for the case where you _want_ 16-byte stack alignment. Instead crazy code like > push %edi > lea 0x8(%esp),%edi > and $0xfffffff0,%esp > pushl -0x4(%edi) > push %ebp > mov %esp,%ebp > ... > call mcount the sane thing to do would be to just do it as push %ebp mov %esp,%ebp call mcount and $0xfffffff0,%esp since - no sane 'mcount' implementation can ever care about 16-byte stack alignment anyway, so aliging the stack before mcount is crazy. - mcount is special anyway, and is the only thing that cares about that whole ebp/return address thing is mcount, and _all_ your games with %edi are about that mcount thing. IOW, once you as a compiler person understand that the 'mcount' call is special, you should have realized that all the work you did for it was totally pointless and stupid to begin with. You must already have that special mcount logic (the whole code to save a register early and push the fake mcount stack frame), so instead of _that_ special logic, change it to a different mcount special logic that associates the 'mcount' call with theframe pointer pushing. That will not only make the Linux kernel tracer happy, it will make all your _other_ users happier too, since you can generate smaller and more efficient code. Admittedly, anybody who compiles with -pg probably doesn't care deeply about smaller and more efficient code, since the mcount call overhead tends to make the thing moot anyway, but it really looks like a win-win situation to just fix the mcount call sequence regardless. > And you didn't provide us with a testcase either ... so please open a > bugzilla and attach preprocessed source of a file that shows the > problem, note the function it happens in and provide the command-line > options you used for building. > > Otherwise it's going to be all speculation on our side. See above - all you need to do is to just fix mcount calling. Now, there is a separate bug that shows that you seem to over-align the stack when not asked for, and yes, since we noticed that I hope that Thomas and friends will fix that, but I think your mcount logic could (and should) be fixed as an independent sillyness. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/