Revert back frame pointers for s390x (remove -fno-omit-frame-pointer but use -mbackchain)
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Ubuntu on IBM z Systems |
Fix Released
|
Undecided
|
bugproxy | |||
dpkg (Ubuntu) | Status tracked in Oracular | |||||
Noble |
Fix Released
|
Undecided
|
Unassigned | |||
Oracular |
Fix Released
|
Undecided
|
Unassigned | |||
glibc (Ubuntu) | Status tracked in Oracular | |||||
Noble |
Fix Released
|
Undecided
|
Unassigned | |||
Oracular |
Fix Released
|
Undecided
|
Unassigned | |||
linux (Ubuntu) | Status tracked in Oracular | |||||
Noble |
Fix Released
|
Undecided
|
Unassigned | |||
Oracular |
Fix Released
|
Undecided
|
Unassigned |
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-
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-
* 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:/
https:/
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/
<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-
* 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.
tags: | added: reverse-proxy-bugzilla |
Changed in ubuntu-z-systems: | |
assignee: | nobody → bugproxy (bugproxy) |
tags: | added: architecture-s39064 bugnameltc-207400 severity-medium targetmilestone-inin--- |
summary: |
- Revert back frame pointers for s390x (remove -fno-omit-framepointer but + Revert back frame pointers for s390x (remove -fno-omit-frame-pointer but use -mbackchain) |
description: | updated |
description: | updated |
description: | updated |
description: | updated |
Hi there,
The bug description only mentioned the situation with GCC. I wonder what the story is with other toolchains like Clang and/or other LLVM-based compilers (e.g. rustc/ldc/julia etc)? Some of the toolchains do support the `-mbacktrace`-like option on s390x, while the rest do not allow you to specify this option.