quoted

quoted

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.

Yes, and this is (supposedly) why GCC does not like seeing -pg and
-fomit-frame-pointer at the same time -- because that cannot work
*on some architectures*.  These are the same architectures that
do not enable -fomit-frame-pointer automatically at -O.

quoted

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.

No.  -fomit-frame-pointer is only the default when optimising on
archs/ABIs where it doesn't hinder debugging and -pg and all that
goodness; specifically, you do not get it by default on x86, not
at any optimisation level.


Segher