| 2024-05-01 18:52:23 |
Frank Heimes |
bug |
|
|
added bug |
| 2024-05-01 19:15:35 |
Steve Langasek |
bug task added |
|
dpkg (Ubuntu) |
|
| 2024-05-06 07:43:30 |
Simon Chopin |
bug task added |
|
glibc (Ubuntu) |
|
| 2024-05-06 07:44:32 |
Simon Chopin |
nominated for series |
|
Ubuntu Noble |
|
| 2024-05-06 07:44:32 |
Simon Chopin |
bug task added |
|
dpkg (Ubuntu Noble) |
|
| 2024-05-06 07:44:32 |
Simon Chopin |
bug task added |
|
glibc (Ubuntu Noble) |
|
| 2024-05-06 07:44:32 |
Simon Chopin |
nominated for series |
|
Ubuntu Oracular |
|
| 2024-05-06 07:44:32 |
Simon Chopin |
bug task added |
|
dpkg (Ubuntu Oracular) |
|
| 2024-05-06 07:44:32 |
Simon Chopin |
bug task added |
|
glibc (Ubuntu Oracular) |
|
| 2024-07-08 08:12:21 |
Frank Heimes |
tags |
s390x |
reverse-proxy-bugzilla s390x |
|
| 2024-07-08 08:12:45 |
Frank Heimes |
ubuntu-z-systems: assignee |
|
bugproxy (bugproxy) |
|
| 2024-07-10 11:19:29 |
bugproxy |
tags |
reverse-proxy-bugzilla s390x |
architecture-s39064 bugnameltc-207400 reverse-proxy-bugzilla s390x severity-medium targetmilestone-inin--- |
|
| 2024-07-11 06:24:04 |
Frank Heimes |
bug task added |
|
linux (Ubuntu) |
|
| 2024-07-15 08:41:46 |
Frank Heimes |
summary |
Revert back frame pointers for s390x (remove -fno-omit-framepointer but use -mbackchain) |
Revert back frame pointers for s390x (remove -fno-omit-frame-pointer but use -mbackchain) |
|
| 2024-07-17 14:10:12 |
Matthias Klose |
dpkg (Ubuntu Oracular): status |
New |
Fix Released |
|
| 2024-08-08 09:16:55 |
Łukasz Zemczak |
dpkg (Ubuntu Noble): status |
New |
Fix Committed |
|
| 2024-08-08 09:16:58 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-08-08 09:17:01 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2024-08-08 09:17:05 |
Łukasz Zemczak |
tags |
architecture-s39064 bugnameltc-207400 reverse-proxy-bugzilla s390x severity-medium targetmilestone-inin--- |
architecture-s39064 bugnameltc-207400 reverse-proxy-bugzilla s390x severity-medium targetmilestone-inin--- verification-needed verification-needed-noble |
|
| 2024-08-08 14:29:44 |
Frank Heimes |
description |
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. |
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. |
|
| 2024-08-08 14:35:41 |
Frank Heimes |
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. |
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 ]
* These changes were implemented during the opening of the oracular series.
The very same changes are backported to 24.04 LTS.
* These only affect the ppc64el and s390x architectures,
for other architectures it's a no-change upload.
* We didn't see any fallout for these changes during the development
on the oracular series, and therefore don't expect any fallout or
regressions in 24.04 LTS either. |
|
| 2024-08-12 08:32:39 |
Łukasz Zemczak |
glibc (Ubuntu Noble): status |
New |
Fix Committed |
|
| 2024-08-12 09:13:22 |
Matthias Klose |
tags |
architecture-s39064 bugnameltc-207400 reverse-proxy-bugzilla s390x severity-medium targetmilestone-inin--- verification-needed verification-needed-noble |
architecture-s39064 bugnameltc-207400 reverse-proxy-bugzilla s390x severity-medium targetmilestone-inin--- verification-done verification-done-noble |
|
