[PATCH] Omit frame pointer and fix %ebp by default on x86 (take 3)
Mon Aug 16 18:35:00 GMT 2004
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
> 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?
More information about the Gcc-patches