public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-kbuild <linux-kbuild@vger.kernel.org>,
	Michal Marek <mmarek@suse.cz>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andi Kleen <andi@firstfloor.org>, Ingo Molnar <mingo@elte.hu>,
	Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: RFC: How to handle function tracing, frame pointers and -mfentry?
Date: Sat, 28 Apr 2012 10:36:03 +0200	[thread overview]
Message-ID: <20120428083603.GJ27374@one.firstfloor.org> (raw)
In-Reply-To: <1335552399.28106.228.camel@gandalf.stny.rr.com>

> 1) Have kconfig detect if -mfentry is supported with the current
> compiler. If it is, then enable a "auto" config called
> CONFIG_CC_HAS_FENTRY, and allow function tracer be able to select
> FRAME_POINTER if that's not defined.
> 
> I actually got this to work, but it only works if the host compiler is
> the same as the compiler building the kernel. Which in lots of cases is
> not (my default setup does not have this).

Kconfig just needs to learn how to run the target compiler

I think that's the right direction. Right now our main
Makefiles get polluted more and more with "test compiles", each
of which makes a "null make" slower and slower. 

I just measured and a null compile (nothing changes) of a current
tree calls "gcc" 141 times.

All this stuff should be cached in the Kconfig instead.

It may break some obscure setups (that can be probably fixed without
too much effort), but the development turnaround improvement
for everyone else would be worth it.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

  parent reply	other threads:[~2012-04-28  8:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-27 18:46 RFC: How to handle function tracing, frame pointers and -mfentry? Steven Rostedt
2012-04-27 19:43 ` Steven Rostedt
2012-04-27 20:27 ` Sam Ravnborg
2012-04-27 20:31   ` H. Peter Anvin
2012-04-27 20:57     ` Steven Rostedt
2012-04-27 21:11       ` H. Peter Anvin
2012-04-27 21:27         ` Steven Rostedt
2012-04-28  8:36 ` Andi Kleen [this message]
2012-04-28  8:50   ` Sam Ravnborg
2012-04-28  9:11     ` Sam Ravnborg
2012-04-28 12:16       ` Andi Kleen
2012-04-28 16:34   ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120428083603.GJ27374@one.firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=hpa@linux.intel.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mmarek@suse.cz \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox