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

From: Jakub Jelinek
Date: Wed Nov 25 2009 - 11:46:14 EST


On Wed, Nov 25, 2009 at 04:44:52PM +0100, Ingo Molnar wrote:
>
> * Thomas Gleixner <tglx@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/