The preferred way of doing stack unwinding on Linux on Z is via dwarf call frame information.
In absence of a dwarf unwinder (as in the Linux kernel) a stack chain can be maintained at runtime in addition to the dwarf unwinding information.
This allows for simple backtrace implementations, but imposes a small runtime overhead. For this to work, all code that might be part of backtrace must be built with the -mbackchain GCC option.
The -fno-omit-framepointer switch is neither necessary nor helpful in this context.
Having a (soft/simulated) frame pointer does not improve backtraces at all on IBM Z.
However, forcing a frame pointer via the -fno-omit-frame-pointer option negatively affects performance for multiple reasons: extra prologue/epilogue overhead and fewer shrink-wrapping opportunities.
Given -fno-omit-frame-pointer does not provide any improvements (backtraces or otherwise) and only reduces performance, -fno-omit-frame-pointers should not be used on IBM Z.
The preferred way of doing stack unwinding on Linux on Z is via dwarf call frame information.
In absence of a dwarf unwinder (as in the Linux kernel) a stack chain can be maintained at runtime in addition to the dwarf unwinding information.
This allows for simple backtrace implementations, but imposes a small runtime overhead. For this to work, all code that might be part of backtrace must be built with the -mbackchain GCC option.
The -fno-omit- framepointer switch is neither necessary nor helpful in this context. frame-pointer option negatively affects performance for multiple reasons: extra prologue/epilogue overhead and fewer shrink-wrapping opportunities. frame-pointer does not provide any improvements (backtraces or otherwise) and only reduces performance, -fno-omit- frame-pointers should not be used on IBM Z.
Having a (soft/simulated) frame pointer does not improve backtraces at all on IBM Z.
However, forcing a frame pointer via the -fno-omit-
Given -fno-omit-