** Description changed: - The preferred way of doing stack unwinding on Linux on Z is via dwarf call frame information. + SRU Justification: + + [ Impact ] + + * 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. + * 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. + + * So we are facing here a performance penalty without any gain - on + this particular platform. + + * And sometimes (in rare cases like LP#2060108) frame pointers may even + lead to failed builds. + + [ Test Plan ] + + * Due to the above description of the impact and rationale, + this pragmatic approach for testing is given: + + * Build the affected packages where frame-pointers should be reverted + using the updated dpkg package (that incl. the modified build defaults) + on (or for) this particular platform. + + * Now frame-pointer usage be checked in the following different ways: + + * 1) For the ease of use (and thanks to Julian Klode), there is this python + test script available that allows to verify a binary in regard to + frame pointers: + https://gist.github.com/julian-klode/85e55553f85c410a1b856a93dce77208 + + * 2) Another more manual way is to verify based on debug symbols like this: + - find and install the ddeb package + - maybe extract the file (e.g. unzstd) + - use 'readelf -wi' + - and grep for 'DW_AT_produce' (build options) + - look for entries regarding frame-pointer + The output may look similar to this: + readelf -wi ./usr/lib/debug/lib/modules/6.8.0-38-generic/kernel/arch/s390/crypto/aes_s390.ko | grep DW_AT_produce + <23> DW_AT_producer : (indirect string, offset: 0x7d): GNU AS 2.42 + <129> DW_AT_producer : (indirect string, offset: 0x3eef): GNU C11 13.2.0 -m64 -mpacked-stack -mbackchain -msoft-float -march=z13 -mtune=z16 -mindirect-branch=thunk-extern -mfunction-return=thunk-extern -mindirect-branch-table -mrecord-mcount -mnop-mcount -mfentry -mzarch -g -gdwarf-5 -O2 -std=gnu11 -p -fshort-wchar -funsigned-char -fno-common -fno-strict-aliasing -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -fno-allow-store-data-races -fno-stack-protector -ftrivial-auto-var-init=zero -fno-stack-clash-protection -fzero-call-used-regs=used-gpr -fno-inline-functions-called-once -falign-functions=8 -fstrict-flex-arrays=3 -fno-strict-overflow -fstack-check=no -fconserve-stack -fsanitize=bounds-strict -fsanitize=shift -fsanitize=bool -fsanitize=enum -fPIC + + * 3) And maybe watching the build messages / log for the build options that + were used (but that is probably not sufficient - it's better to inspect + the output.) + + [ Where problems could occur ] + + * The dpkg modifications could have been done erroneously. + A dpkg test build and/or builds of other packages with the modified dpkg + version in place would show this. + + * The settings in dpkg might be overwritten by other settings/packages. + Tests like above, would show this. + + * One may think there could be issues in an environment where some packages + have frame-pointer enabled and other don't. + This is fine and was confirmed by IBM toolchain team and ours + (as well as by a longer running <weeks> test system, + with FP disabled in kernel, that showed no issues - like expected). + + [ Other Info ] + + * This revert of the frame-pointer setting is limited to IBM platforms. + + * The dpkg package that reverts frame pointer was already uploaded + for oracular.
-- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/2064538 Title: Revert back frame pointers for s390x (remove -fno-omit-frame-pointer but use -mbackchain) Status in Ubuntu on IBM z Systems: New Status in dpkg package in Ubuntu: Fix Released Status in glibc package in Ubuntu: New Status in linux package in Ubuntu: New Status in dpkg source package in Noble: Fix Committed Status in glibc source package in Noble: New Status in linux source package in Noble: New Status in dpkg source package in Oracular: Fix Released Status in glibc source package in Oracular: New Status in linux source package in Oracular: New Bug description: SRU Justification: [ Impact ] * 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. * So we are facing here a performance penalty without any gain - on this particular platform. * And sometimes (in rare cases like LP#2060108) frame pointers may even lead to failed builds. [ Test Plan ] * Due to the above description of the impact and rationale, this pragmatic approach for testing is given: * Build the affected packages where frame-pointers should be reverted using the updated dpkg package (that incl. the modified build defaults) on (or for) this particular platform. * Now frame-pointer usage be checked in the following different ways: * 1) For the ease of use (and thanks to Julian Klode), there is this python test script available that allows to verify a binary in regard to frame pointers: https://gist.github.com/julian-klode/85e55553f85c410a1b856a93dce77208 * 2) Another more manual way is to verify based on debug symbols like this: - find and install the ddeb package - maybe extract the file (e.g. unzstd) - use 'readelf -wi' - and grep for 'DW_AT_produce' (build options) - look for entries regarding frame-pointer The output may look similar to this: readelf -wi ./usr/lib/debug/lib/modules/6.8.0-38-generic/kernel/arch/s390/crypto/aes_s390.ko | grep DW_AT_produce <23> DW_AT_producer : (indirect string, offset: 0x7d): GNU AS 2.42 <129> DW_AT_producer : (indirect string, offset: 0x3eef): GNU C11 13.2.0 -m64 -mpacked-stack -mbackchain -msoft-float -march=z13 -mtune=z16 -mindirect-branch=thunk-extern -mfunction-return=thunk-extern -mindirect-branch-table -mrecord-mcount -mnop-mcount -mfentry -mzarch -g -gdwarf-5 -O2 -std=gnu11 -p -fshort-wchar -funsigned-char -fno-common -fno-strict-aliasing -fno-asynchronous-unwind-tables -fno-delete-null-pointer-checks -fno-allow-store-data-races -fno-stack-protector -ftrivial-auto-var-init=zero -fno-stack-clash-protection -fzero-call-used-regs=used-gpr -fno-inline-functions-called-once -falign-functions=8 -fstrict-flex-arrays=3 -fno-strict-overflow -fstack-check=no -fconserve-stack -fsanitize=bounds-strict -fsanitize=shift -fsanitize=bool -fsanitize=enum -fPIC * 3) And maybe watching the build messages / log for the build options that were used (but that is probably not sufficient - it's better to inspect the output.) [ Where problems could occur ] * The dpkg modifications could have been done erroneously. A dpkg test build and/or builds of other packages with the modified dpkg version in place would show this. * The settings in dpkg might be overwritten by other settings/packages. Tests like above, would show this. * One may think there could be issues in an environment where some packages have frame-pointer enabled and other don't. This is fine and was confirmed by IBM toolchain team and ours (as well as by a longer running <weeks> test system, with FP disabled in kernel, that showed no issues - like expected). [ Other Info ] * This revert of the frame-pointer setting is limited to IBM platforms. * The dpkg package that reverts frame pointer was already uploaded for oracular. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2064538/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
