This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
- From: "H. Peter Anvin" <hpa at zytor dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Ingo Molnar <mingo at elte dot hu>, Thomas Gleixner <tglx at linutronix dot de>, Andrew Haley <aph at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, rostedt at goodmis dot org, LKML <linux-kernel at vger dot kernel dot org>, Andrew Morton <akpm at linux-foundation dot org>, Heiko Carstens <heiko dot carstens at de dot ibm dot com>, feng dot tang at intel dot com, Peter Zijlstra <peterz at infradead dot org>, Frederic Weisbecker <fweisbec at gmail dot com>, David Daney <ddaney at caviumnetworks dot com>, Richard Guenther <richard dot guenther at gmail dot com>, gcc <gcc at gcc dot gnu dot org>, Linus Torvalds <torvalds at linux-foundation dot org>
- Date: Wed, 25 Nov 2009 12:12:49 -0800
- Subject: Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC messing with mcount prologue
- References: <1258736456.22249.1032.camel@gandalf.stny.rr.com> <4B06EF6F.2050507@redhat.com> <6dc9ffc80911220138y15bfa91agccf5c29f1c30e09a@mail.gmail.com> <4B0972C9.302@redhat.com> <6dc9ffc80911221530t38d83cf6je739743c8d756667@mail.gmail.com> <4B0BF119.4070704@redhat.com> <alpine.LFD.2.00.0911241555170.24119@localhost.localdomain> <20091124150604.GJ22813@hs20-bc2-1.build.redhat.com> <alpine.LFD.2.00.0911251604280.24119@localhost.localdomain> <20091125154452.GA9456@elte.hu> <20091125164434.GS22813@hs20-bc2-1.build.redhat.com>
On 11/25/2009 08:44 AM, Jakub Jelinek wrote:
>
> 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.
>
There is really just one that makes sense, which is providing the
ABI-defined entry state, which means intercepting at the point of entry.
Anything else is/was a mistake.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.