[PATCH] Omit frame pointer and fix %ebp by default on x86 (take 3)

[Andrew Haley <aph at redhat dot com>]

Roger Sayle writes:
 > 
 >  In GCC's case, it's not -fomit-frame-pointer that causes problems
 > for stack unwinding and glibc's backtrace, but the use of %ebp once
 > it isn't needed required as a frame pointer.  If a function
 > allocates %ebp as a general purpose register across a function
 > caller, that function will dutifully preserve %ebp as a
 > callee-saved register in it's stack frame, resulting in garbage in
 > the linked list of frames that backtrace(3) expects to be able to
 > traverse.
 > 
 > The solution is to consider the ability to avoid saving and restoring
 > %ebp in a function as independent of whether we allow %ebp to be used
 > as a spare register.  Fortunately, GCC already allows this through
 > the combination of "-fomit-frame-pointer" and "-ffixed-ebp".  This
 > allows GCC to avoid the overhead of building stack frames, but still
 > take avoid problems for languages/run-times that expect to unwind
 > through the stack.
 > 
 > In this light, the i386 backend's -momit-leaf-frame pointer can be
 > seen as avoiding problems, as the use of %ebp to hold arbitrary
 > values avoids corrupting the backtrace chain.  Unfortunately, this
 > is a partial solution as non-call traps, interrupts and signals
 > can still potentially encounter problems.
 > 
 > 
 > The simple patch below tweaks the i386 backend, such that we now
 > default to the equivalent of "-fomit-frame-pointer -ffixed-ebp" on
 > 32-bit targets, when optimizing and the user hasn't explicitly
 > specified a frame pointer option, either -fomit-frame-pointer,
 > -fno-omit-frame-pointer or -momit-leaf-frame-pointer.

I don't understand this.  What will backtrace() do if there is no
frame pointer?  Will it provide a full call stack trace or not?

Andrew.