[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B0C13F4.5090106@redhat.com>
Date: Tue, 24 Nov 2009 17:12:20 +0000
From: Andrew Haley <aph@...hat.com>
To: "H. Peter Anvin" <hpa@...or.com>
CC: Jakub Jelinek <jakub@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
"H.J. Lu" <hjl.tools@...il.com>, rostedt@...dmis.org,
Ingo Molnar <mingo@...e.hu>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Heiko Carstens <heiko.carstens@...ibm.com>,
feng.tang@...el.com, Peter Zijlstra <peterz@...radead.org>,
Frederic Weisbecker <fweisbec@...il.com>,
David Daney <ddaney@...iumnetworks.com>,
Richard Guenther <richard.guenther@...il.com>,
gcc <gcc@....gnu.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH][GIT PULL][v2.6.32] tracing/x86: Add check to detect GCC
messing with mcount prologue
H. Peter Anvin wrote:
> On 11/24/2009 07:46 AM, Andrew Haley wrote:
>>> Yes, a lot. The difference is that -maccumulate-outgoing-args allocates
>>> space for arguments of the callee with most arguments in the prologue, using
>>> subtraction from sp, then to pass arguments uses movl XXX, 4(%esp) etc.
>>> and the stack pointer doesn't usually change within the function (except for
>>> alloca/VLAs).
>>> With -mno-accumulate-outgoing-args args are pushed using push instructions
>>> and stack pointer is constantly changing.
>> Alright. So, it is possible in theory for gcc to generate code that
>> only uses -maccumulate-outgoing-args when it needs to realign SP.
>> And, therefore, we could have a nice option for the kernel: one with
>> (mostly) good code density and never generates the bizarre code
>> sequence in the prologue.
>
> If we're changing gcc anyway, then let's add the option of intercepting
> the function at the point where the machine state is well-defined by
> ABI, which is before the function stack frame is set up.
Hmm. On the x86 I suppose we could just inject a naked call instruction,
but not all aeches allow us to call anything before we've saved the return
address. Or are you talking x86 only?
Andrew.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists