| 2024-05-01 18:55:50 |
Frank Heimes |
bug |
|
|
added bug |
| 2024-05-01 19:15:38 |
Steve Langasek |
bug task added |
|
dpkg (Ubuntu) |
|
| 2024-05-06 07:44:14 |
Simon Chopin |
bug task added |
|
glibc (Ubuntu) |
|
| 2024-05-06 07:44:42 |
Simon Chopin |
nominated for series |
|
Ubuntu Noble |
|
| 2024-05-06 07:44:42 |
Simon Chopin |
bug task added |
|
dpkg (Ubuntu Noble) |
|
| 2024-05-06 07:44:42 |
Simon Chopin |
bug task added |
|
glibc (Ubuntu Noble) |
|
| 2024-05-06 07:44:42 |
Simon Chopin |
nominated for series |
|
Ubuntu Oracular |
|
| 2024-05-06 07:44:42 |
Simon Chopin |
bug task added |
|
dpkg (Ubuntu Oracular) |
|
| 2024-05-06 07:44:42 |
Simon Chopin |
bug task added |
|
glibc (Ubuntu Oracular) |
|
| 2024-07-11 13:31:20 |
Frank Heimes |
bug task added |
|
linux (Ubuntu) |
|
| 2024-07-15 08:41:55 |
Frank Heimes |
summary |
Revert back frame pointers for ppc64el (remove -fno-omit-framepointer) |
Revert back frame pointers for ppc64el (remove -fno-omit-frame-pointer) |
|
| 2024-07-17 14:11:16 |
Matthias Klose |
dpkg (Ubuntu Oracular): status |
New |
Fix Released |
|
| 2024-08-01 07:01:29 |
Matthias Klose |
attachment added |
|
dpkg.debdiff https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/2064539/+attachment/5801859/+files/dpkg.debdiff |
|
| 2024-08-01 07:04:56 |
Matthias Klose |
description |
Power's Linux ABIs all require an explicit call chain be stored on the call stack frames which are all accessible via the stack pointer.
Therefore, having a (soft/simulated) frame pointer does not improve backtraces at all on Power.
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 Power. |
Power's Linux ABIs all require an explicit call chain be stored on the call stack frames which are all accessible via the stack pointer.
Therefore, having a (soft/simulated) frame pointer does not improve backtraces at all on Power.
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 Power.
SRU:
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-01 08:13:55 |
Matthias Klose |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2024-08-08 09:17:10 |
Łukasz Zemczak |
dpkg (Ubuntu Noble): status |
New |
Fix Committed |
|
| 2024-08-08 09:17:15 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2024-08-08 09:17:19 |
Łukasz Zemczak |
tags |
ppc64el |
ppc64el verification-needed verification-needed-noble |
|
| 2024-08-08 14:36:25 |
Frank Heimes |
description |
Power's Linux ABIs all require an explicit call chain be stored on the call stack frames which are all accessible via the stack pointer.
Therefore, having a (soft/simulated) frame pointer does not improve backtraces at all on Power.
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 Power.
SRU:
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. |
SRU Justification:
[ Impact ]
* Power's Linux ABIs all require an explicit call chain be stored on the call stack frames which are all accessible via the stack pointer.
* Therefore, having a (soft/simulated) frame pointer does not improve backtraces at all on Power.
* 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 Power.
* 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:59 |
Łukasz Zemczak |
glibc (Ubuntu Noble): status |
New |
Fix Committed |
|
| 2024-08-12 09:13:56 |
Matthias Klose |
tags |
ppc64el verification-needed verification-needed-noble |
ppc64el verification-done verification-done-noble |
|
| 2024-08-19 10:38:56 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2024-08-19 10:41:35 |
Launchpad Janitor |
dpkg (Ubuntu Noble): status |
Fix Committed |
Fix Released |
|
| 2024-08-19 12:29:40 |
Ubuntu Foundations Team Bug Bot |
tags |
ppc64el verification-done verification-done-noble |
patch ppc64el verification-done verification-done-noble |
|
| 2024-08-19 12:29:47 |
Ubuntu Foundations Team Bug Bot |
bug |
|
|
added subscriber Terry Rudd |
| 2024-08-19 14:54:24 |
Simon Chopin |
glibc (Ubuntu Oracular): status |
New |
Fix Committed |
|
| 2024-08-21 15:36:02 |
Launchpad Janitor |
glibc (Ubuntu Noble): status |
Fix Committed |
Fix Released |
|
| 2024-08-22 10:57:30 |
Launchpad Janitor |
glibc (Ubuntu Oracular): status |
Fix Committed |
Fix Released |
|
| 2024-08-26 09:01:14 |
Frank Heimes |
description |
SRU Justification:
[ Impact ]
* Power's Linux ABIs all require an explicit call chain be stored on the call stack frames which are all accessible via the stack pointer.
* Therefore, having a (soft/simulated) frame pointer does not improve backtraces at all on Power.
* 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 Power.
* 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. |
SRU Justification:
[ Impact ]
* Power's Linux ABIs all require an explicit call chain be stored on the call stack frames which are all accessible via the stack pointer.
* Therefore, having a (soft/simulated) frame pointer does not improve backtraces at all on Power.
* 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 Power.
* 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
https://gist.githubusercontent.com/julian-klode/85e55553f85c410a1b856a93dce77208/raw/488b8509e6f23fe48f917961fe711b285dcb2e28/dwprod.py
requires python3-pyelftools
* 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-26 12:15:11 |
Frank Heimes |
linux (Ubuntu Noble): status |
New |
Fix Released |
|
| 2024-08-26 12:15:30 |
Frank Heimes |
linux (Ubuntu Oracular): status |
New |
Fix Released |
|
| 2024-08-26 12:15:45 |
Frank Heimes |
ubuntu-power-systems: status |
New |
Fix Released |
|
