[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 07 Aug 2012 16:57:58 -0700
From: John Reiser <jreiser@...wagon.com>
To: Steven Rostedt <rostedt@...dmis.org>
CC: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Frederic Weisbecker <fweisbec@...il.com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andi Kleen <andi@...stfloor.org>
Subject: Re: [RFC PATCH 1/4] ftrace: Make recordmcount.c handle __fentry__
On 08/07/2012 12:38 PM, Steven Rostedt wrote:
> From: Steven Rostedt <srostedt@...hat.com>
>
> With gcc 4.6.0 the -mfentry feature places the function profiling call at the start of the function. When this is used, the call is to __fentry__ and not mcount.
>
> Change recordmcount.c to record both callers to __fentry__ and mcount.
[snip]
> - (altmcount && strcmp(altmcount, symname) == 0))
> + (altmcount && strcmp(altmcount, symname) == 0) ||
> + (strcmp(fentry, symname) == 0))
The proposed change will work as long as all the *.o use the same name.
Only one of {"__fentry__", "mcount", "_mcount", altmcount} is allowed
for all the *.o as input for a particular run. [Modulo the hack
of ignoring a leading '.' for 64-bit PowerPC, of course.]
If the user changes compilers (or changes CFLAGS by insert/remove "-mfentry")
without doing a "make clean", then recordmcount will omit some calls.
Those restrictions are easy to guess, and recovery is easy. Therefore,
Ack'ed by: John Reiser <jreiser@...wagon.com>
--
--
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