From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Mon, 28 Jul 2008 15:54:30 +0100 (BST) From: Hugh Dickins To: Ingo Molnar Subject: Re: CONFIG_FRAME_POINTER [was [PATCH] x86: BUILD_IRQ say .text] In-Reply-To: <20080728144133.GH18144@elte.hu> Message-ID: References: <20080724104459.GI28817@elte.hu> <20080728144133.GH18144@elte.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: the arch/x86 maintainers , linux-kernel@vger.kernel.org, Mike Travis , Linuxppc-dev@ozlabs.org, Linus Torvalds , Arjan van de Ven List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, 28 Jul 2008, Ingo Molnar wrote: > * Hugh Dickins wrote: > > > I rather think CONFIG_FRAME_POINTER shouldn't exist at all (or be a > > private, config-user-invisible, specific-to-a-few-arches thing): what > > one wants to configure is how far to sacrifice cpu performance and > > kernel smallness to getting a good stacktrace. Frame pointer is just > > an implementation detail on that, appropriate to some arches. Perhaps > > three settings: no stacktrace, fair stacktrace, best stacktrace. > > actually, we consciously use and rely on frame pointers on x86. The > runtime cost on 64-bit is miniscule and the improved backtrace output in > recent kernels makes backtraces _much_ easier to interpret: Just to clarify, no way was I criticizing the use of frame pointers on x86. What I don't care for is that CONFIG_FRAME_POINTER is used by common code (e.g. top level Makefile, and various debug Kconfigs), when I see it as an arch-specific technique for getting best stacktrace. Hugh