[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B05B4B5.2000102@redhat.com>
Date: Thu, 19 Nov 2009 14:12:21 -0700
From: Jeff Law <law@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: "H. Peter Anvin" <hpa@...or.com>, rostedt@...dmis.org,
David Daney <ddaney@...iumnetworks.com>,
Andrew Haley <aph@...hat.com>,
Richard Guenther <richard.guenther@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
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, Fr??d??ric Weisbecker <fweisbec@...il.com>,
Peter Zijlstra <peterz@...radead.org>, jakub@...hat.com,
gcc@....gnu.org
Subject: Re: BUG: GCC-4.4.x changes the function frame on some functions
On 11/19/09 13:06, Linus Torvalds wrote:
>
> On Thu, 19 Nov 2009, H. Peter Anvin wrote:
>
>> Calling the profiler immediately at the entry point is clearly the more
>> sane option. It means the ABI is well-defined, stable, and independent
>> of what the actual function contents are. It means that ABI isn't the
>> normal C ABI (the __fentry__ function would have to preserve all
>> registers), but that's fine...
>>
> As far as I know, that's true of _mcount already: it's not a normal ABI
> and is rather a highly architecture-specific special case to begin with.
> At least ARM has some (several?) special mcount calling conventions,
> afaik.
>
Correct. _mcount's ABI typically has been defined by the implementation
of the vendor's C library mcount.
GCC has options to emit the profiling code prior to or after the
prologue controllable through the usual variety of target macros &
hooks. I can't imagine anyone would object to a clean, tested patch to
change how x86-linux's profiling code was implemented.
jeff
--
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