From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-158136-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 17568 invoked by alias); 19 Nov 2009 20:29:59 -0000
Received: (qmail 17554 invoked by uid 22791); 19 Nov 2009 20:29:58 -0000
X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 	tests=AWL,BAYES_00,SPF_PASS
X-Spam-Check-By: sourceware.org
Received: from mail-ew0-f227.google.com (HELO mail-ew0-f227.google.com) (209.85.219.227)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 19 Nov 2009 20:28:51 +0000
Received: by ewy27 with SMTP id 27so30525ewy.16         for <gcc@gcc.gnu.org>; Thu, 19 Nov 2009 12:28:48 -0800 (PST)
Received: by 10.213.96.83 with SMTP id g19mr466039ebn.20.1258662528390;         Thu, 19 Nov 2009 12:28:48 -0800 (PST)
Received: from nowhere (ADijon-552-1-120-36.w92-148.abo.wanadoo.fr [92.148.63.36])         by mx.google.com with ESMTPS id 10sm222803eyd.13.2009.11.19.12.28.45         (version=SSLv3 cipher=RC4-MD5);         Thu, 19 Nov 2009 12:28:47 -0800 (PST)
Received: by nowhere (nbSMTP-1.00) for uid 1000 	(using TLSv1/SSLv3 with cipher RC4-MD5 (128/128 bits)) 	fweisbec@gmail.com; Thu, 19 Nov 2009 21:28:50 +0100 (CET)
Date: Thu, 19 Nov 2009 20:29:00 -0000
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: David Daney <ddaney@caviumnetworks.com>, 	Linus Torvalds <torvalds@linux-foundation.org>, 	Andrew Haley <aph@redhat.com>, 	Richard Guenther <richard.guenther@gmail.com>, 	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>, 	"H. Peter Anvin" <hpa@zytor.com>, 	LKML <linux-kernel@vger.kernel.org>, 	Andrew Morton <akpm@linux-foundation.org>, 	Heiko Carstens <heiko.carstens@de.ibm.com>, feng.tang@intel.com, 	Peter Zijlstra <peterz@infradead.org>, jakub@redhat.com, 	gcc@gcc.gnu.org
Subject: Re: BUG: GCC-4.4.x changes the function frame on some functions
Message-ID: <20091119202845.GH4967@nowhere>
References: <84fc9c000911191003t244eb864o3d5b355ab5485f@mail.gmail.com> <4B058CCD.8050605@redhat.com> <alpine.LFD.2.00.0911191039470.2793@localhost.localdomain> <alpine.LFD.2.00.0911191041471.2793@localhost.localdomain> <alpine.LFD.2.00.0911191047350.2793@localhost.localdomain> <4B05982B.6060200@caviumnetworks.com> <1258658886.22249.874.camel@gandalf.stny.rr.com> <20091119194625.GE4967@nowhere> <1258661141.22249.962.camel@gandalf.stny.rr.com> <1258661836.22249.995.camel@gandalf.stny.rr.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1258661836.22249.995.camel@gandalf.stny.rr.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2009-11/txt/msg00536.txt.bz2

On Thu, Nov 19, 2009 at 03:17:16PM -0500, Steven Rostedt wrote:
> On Thu, 2009-11-19 at 15:05 -0500, Steven Rostedt wrote:
> 
> > Well, other archs use a register to store the return address. But it
> > would also be easy to do (pseudo arch assembly):
> > 
> > 	<function>:
> > 		mov lr, (%sp)
> > 		add 8, %sp
> > 		blr __fentry__
> 
> Should be bl __fentry__ for "branch and link".
> 
> > 		sub 8, %sp
> > 		mov (%sp), lr
> > 
> > 
> > That way the lr would have the current function, and the parent would
> > still be at 8(%sp)
> 
> Actually, if we add a new profiler and can make our own specification, I
> would say that the add and sub lines be the responsibility of
> __fentry__. Then we would have:
> 
> 	<function>:
> 		mov lr, (%sp)
> 		bl __fentry__
> 		mov (%sp), lr
> 
> If sp points to the current content, then replace (%sp) above with 
> -8(%sp).  Then the implementation of a nop __fentry__ would simply be:
> 
> 	__fentry__:
> 		blr


Good point!

 
> For anything more elaborate, __fentry__ would be responsible for all
> adjustments.


Yep. The more we control it from __fentry__, the less we fall
down into unexpected surprises.