Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue

From: Jakub Jelinek <jakub@redhat.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Andrew Haley <aph@redhat.com>, "H.J. Lu" <hjl.tools@gmail.com>,
	rostedt@goodmis.org, "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>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	David Daney <ddaney@caviumnetworks.com>,
	Richard Guenther <richard.guenther@gmail.com>,
	gcc <gcc@gcc.gnu.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
Date: Wed, 25 Nov 2009 11:44:34 -0500	[thread overview]
Message-ID: <20091125164434.GS22813@hs20-bc2-1.build.redhat.com> (raw)
In-Reply-To: <20091125154452.GA9456@elte.hu>

On Wed, Nov 25, 2009 at 04:44:52PM +0100, Ingo Molnar wrote:
> 
> * Thomas Gleixner <tglx@linutronix.de> wrote:
> 
> > On Tue, 24 Nov 2009, Jakub Jelinek wrote:
> > 
> > > On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
> > > > > you should compile your code with -maccumulate-outgoing-args, and there's
> > > > > no need to use -mtune=generic.  Is that right?
> > > > 
> > > > Seems to work. What other side effects has that ?
> > > 
> > > Faster code, significant increase in code size though.  Note that on many
> > > architectures it is the only supported model.
> > 
> > Just checked on the affected -marchs. The increase in code size is 
> > about 3% which is not that bad and definitely acceptable for the 
> > tracing case. Will zap the -mtune=generic patch and use 
> > -maccumulate-outgoing-args instead.
> 
> hm, 3% sounds quite large :( dyn-ftrace is enabled in distro configs, so 
> 3% is a big deal IMO.

If you compile kernels 90%+ people out there run with -p on i?86/x86_64,
then certainly coming up with a new gcc switch and new profiling ABI is
desirable.  -p on i?86/x86_64 e.g. forces -fno-omit-frame-pointer, which
makes code on these register starved arches significantly worse.
Making GCC output profiling call before prologue instead of after prologue
is a 4 liner in generic code and a few lines in target specific code.
The important thing is that we shouldn't have 100 different profiling ABIs,
so it is desirable to agree on something that will be generally useful not
just for the kernel, but perhaps for other purposes.

	Jakub