From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17626 invoked by alias); 19 Nov 2009 19:12:29 -0000 Received: (qmail 17614 invoked by uid 22791); 19 Nov 2009 19:12:28 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mail3.caviumnetworks.com (HELO mail3.caviumnetworks.com) (12.108.191.235) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Nov 2009 19:11:23 +0000 Received: from caexch01.caveonetworks.com (Not Verified[192.168.16.9]) by mail3.caviumnetworks.com with MailMarshal (v6,5,4,7535) id ; Thu, 19 Nov 2009 11:10:44 -0800 Received: from caexch01.caveonetworks.com ([192.168.16.9]) by caexch01.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 11:10:36 -0800 Received: from dd1.caveonetworks.com ([12.108.191.236]) by caexch01.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 11:10:36 -0800 Message-ID: <4B05982B.6060200@caviumnetworks.com> Date: Thu, 19 Nov 2009 19:12:00 -0000 From: David Daney User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Linus Torvalds CC: Andrew Haley , Richard Guenther , 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 References: <20091119072040.GA23579@elte.hu> <1258653562.22249.682.camel@gandalf.stny.rr.com> <84fc9c000911191003t244eb864o3d5b355ab5485f@mail.gmail.com> <4B058CCD.8050605@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-11/txt/msg00524.txt.bz2 Linus Torvalds wrote: > > On Thu, 19 Nov 2009, Linus Torvalds wrote: >> I bet other people than just the kernel use the mcount hook for subtler >> things than just doing profiles. And even if they don't, the quoted code >> generation is just crazy _crap_. > > For the kernel, if the only case is that timer_stat.c thing that Thomas > pointed at, I guess we can at least work around it with something like the > appended. The kernel code is certainly ugly too, no question about that. > > It's just that we'd like to be able to depend on mcount code generation > not being insane even in the presense of ugly code.. > > The alternative would be to have some warning when this happens, so that > we can at least see it. "mcount won't work reliably" > For the MIPS port of GCC and Linux I recently added the -mmcount-ra-address switch. It causes the location of the return address (on the stack) to be passed to mcount in a scratch register. Perhaps something similar could be done for x86. It would make this patching of the return location more reliable at the expense of more code at the mcount invocation site. For the MIPS case the code size doesn't increase, as it is done in the delay slot of the call instruction, which would otherwise be a nop. David Daney