[Bug 2064538] Re: Revert back frame pointers for s390x (remove -fno-omit-frame-pointer but use -mbackchain)

[Frank Heimes]

** 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 Ubuntu
Foundations Bugs, which is subscribed to glibc 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