-fomit-frame-pointer omits the storing of stack frame pointers during function calls.
The -fomit-frame-pointer option instructs
the compiler to not store stack frame pointers if the function does not need it. You can use
this option to reduce the code image size.
The -fno-omit-frame-pointer option
instructs the compiler to store the stack frame pointer in a register. In AArch32, the frame
pointer is stored in register R11 for A32 code or register
R7 for T32 code. In AArch64, the frame pointer is stored
in register X29. The register that is used as a frame
pointer is not available for use as a general-purpose register. It is available as a
general-purpose register if you compile with -fomit-frame-pointer.
Frame pointer limitations for stack unwinding
Frame pointers enable the compiler to insert code to remove the automatic
variables from the stack when C++ exceptions are thrown. This is called stack unwinding.
However, there are limitations on how the frame pointers are used:
By default, there are no guarantees on the use of the
frame pointers.
There are no guarantees about the use of frame pointers in the C or C++
libraries.
If you specify -fno-omit-frame-pointer,
then any function which uses space on the stack creates a frame record, and changes the
frame pointer to point to it. There is a short time period at the beginning and end of a
function where the frame pointer points to the frame record in the caller's frame.
If you specify -fno-omit-frame-pointer,
then the frame pointer always points to the lowest address of a valid frame record. A
frame record consists of two words:
the value of the frame pointer at function entry in the
lower-addressed word.
the value of the link register at function entry in the
higher-addressed word.
A function that does not use any stack space does not need to create a
frame record, and leaves the frame pointer pointing to the caller's frame.
In AArch32 state, there is currently no reliable way to unwind mixed A32
and T32 code using frame pointers.
The behavior of frame pointers in AArch32 state is not part of the ABI
and therefore might change in the future. The behavior of frame pointers in AArch64 state
is part of the ABI and is therefore unlikely to change.
Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers of your data.