Leaf functions generally do not contain more than half dozen
stackreferences, and are generally called more or equally often as there
callers. The slight overhead of leaf functions that do contain a dozen
stackreferences is much smaller than the overhead of omitting
framepointers in /all/ branch functions including those with dozens of
stackreferences. Maybe gcc's optimizer could be adapted in the (near)
future to compare either speed or sizes of possibly generated code, with
and without framepointer, if the compile is not a debug one.
But in the mean time, in most "userland" projects I've tested with, the
-momit-leaf-frame-pointer resulted in almost te same codesize as
compiles with framepointer, along with more or less the same speed as
"-fomit-frame-pointer". I wouldn't know how to benchmark kernel-configs
though, and I haven't seen anyone doing this with the framepointer
options yet...
> OTOH, AFAIK frame pointers make debugging easier, development kernels
> are better to be compiled with fp in every func.
Honestly, I think that's a shortcoming of the debugger if that's true.
The debugger could store the stackpointer position after a call or
calculate it based on sub/add/push/pop's, instead of borrowing it from
ebp. I'm just concerned about the extra costs (in speed and size) of
always omiting the framepointer.
(It shouldn't be impossible to debug regparm- and stdcall-functions as
well, I wonder why this could be a problem at the moment. But just
"omitting framepointers" at least doesn't mix up the (IMHO: somewhat
thoughtlessly defined) i386 32-bit C-callingconvention.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/