Date:	Tue, 05 May 2009 09:33:02 -0400
From:	Steven Rostedt <srostedt@...hat.com>
To:	Segher Boessenkool <segher@...nel.crashing.org>
Cc:	Anton Vorontsov <avorontsov@...mvista.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	linuxppc-dev@...abs.org, Paul Mackerras <paulus@...ba.org>,
	Sam Ravnborg <sam@...nborg.org>
Subject: Re: [PATCH 1/3] powerpc, Makefile: Make it possible to safely
	select CONFIG_FRAME_POINTER


On Tue, 2009-05-05 at 09:56 +0200, Segher Boessenkool wrote:
> > Yeah, I agree. This needs a better description. I only know what's  
> > going
> > on because I was there for the start of the discussion.
> >
> > But just to be sure, this is what I think is happening.
> >
> > When we add "-pg" to gcc, it automatically causes frame pointers to be
> > used.
> 
> Nope, it does no such thing.

Well, mcount is expected to be able to get to not just who called
mcount, but also the parent of that function. The way mcount is
implemented does not let you do that. If mcount was the first thing to
be called in a function, then it would have been perfect. We could get
to the caller, its parent, and even the parameters. But unfortunately,
mcount is called after the stack is set up. Thus, without frame pointers
(the way to find a previous frame) there's no way (on some archs) to
find the parent. Nor can we figure out the parameters, which really
sucks.


> 
> > But with PPC, it always has frame pointers and there's no problem.
> 
> Well, what do you call a "frame pointer"?  In the general meaning
> of "some register that points to the incoming function arguments
> and the function local variables", PowerPC can _usually_ use GPR1,
> the stack pointer (and indeed it is called "stack frame pointer"
> in the ABI).  In the more narrow meaning of "what GCC calls the
> frame pointer", "the thing that -fomit-frame-pointer optimises
> away" -- on PowerPC (and many other targets), -fomit-frame-pointer
> is the *default* when optimisation is enabled!
> 
> There is a GCC bug here though: it won't allow both -pg and
> -fomit-frame-pointer be set at the command line at the same time,
> even on targets where that is not problematic.
> 
> > But with Linux, when you add CONFIG_FRAME_POINTER, it automatically
> > adds:  -fno-omit-frame-pointer. Thus the config will add
> > "-fomit-frame-pointer" when CONFIG_FRAME_POINTER is not set, or it  
> > will
> > add "-fno-omit-frame-pointer" when it is set.
> >
> > The problem with PPC is that "-fno-omit-frame-pointer" is buggy and
> > causes gcc to produce bad code.
> 
> It's a deeper problem that is only _exposed_ by -fno-o-f-p (and can be
> hidden by -mno-sched-epilog in the one spot where it hit us).
> 
> > Perhaps a better name would be:
> >
> > HAVE_FRAME_POINTER_AS_DEFAULT
> 
> NO_NO_OMIT_FRAME_POINTER ?  Or better, just never use -fno-o-f-p,
> I don't see why you would ever need it.

Because on x86_64 it gives better back traces. x86_64 has no way to get
to the previous frames without it. There's code to use other debug
metadata to get back tracing, but for uses of things like the stack
tracer, we need to be able to use the actual stack frames.

As you said above, -fomit-frame-pointer is default when we optimize, and
that is how the kernel is built. If we optimize on x86_64 and do not use
-fno-omit-frame-pointer, the stack tracer is useless.

-- Steve


--
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