[SRU] dpkg: backport frame-pointer enabling mechanism for Rust

[Zixing Liu]

[ Impact ]

 * On Noble, dpkg scripts could not produce Rust binaries with frame-pointer enabled.

[ Test Plan ]

 * Build a Rust binary package like ripgrep and you will not find frame-pointers being used in the binary.
 * Since LLVM could inline and choose to optimize frame pointers away in some cases, you will need to check the disassembly of the program around the function prologue to see if the frame pointer register is correctly saved to stack (rbp/ebp on x86 architecture). You can use the script provided in https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/2082636/+attachment/5840384/+files/check-rust-fp.py to check if the frame pointers have been enabled.

[ Where problems could occur ]

 * On older Rust versions (Rust <= 1.80), it is known that LLVM on s390x sometimes can produce incorrect warnings about how the "backchain" feature does not exist.
 * On older LLVM versions (LLVM <= 17), LLVM may not produce correct backchain saving logic inside the function prologue.

[ Other Info ]

 * This change is mandatory to enable Rust-related packages with frame-pointers during the build.

[Steve Langasek (vorlon)]

> * Since LLVM could inline and choose to optimize frame pointers away in some cases, you will need to check the disassembly of the program around the function prologue to see if the frame pointer register is correctly saved to stack (rbp/ebp on x86 architecture).

This is incomplete as an SRU test case; it does not tell a random developer what steps to follow to verify the SRU's correctness. Please flesh this out.

[Zixing Liu (liushuyu-011)]

I have attached a script to detect if frame pointers have been enabled for the binary.

If one or two symbols are not enabled, that's fine, and that might be a false-positive due to the script not handling some complicated DWARF operations (DWARF is a Turing-complete descriptor language).

[Steve Langasek (vorlon)]

Which older rust, llvm versions does the "where problems could occur" apply to? Are the versions in noble known to be affected?

[Zixing Liu (liushuyu-011)]

> Which older rust, llvm versions does the "where problems could occur" apply to? Are the versions in noble known to be affected?

This is now cleared up in the updated description (LLVM <= 17 and Rust <= 1.80, where the upstream patches landed).

[Steve Langasek (vorlon)]

> This is now cleared up in the updated description (LLVM <= 17 and Rust <= 1.80, where the upstream patches landed).

Ok.

rustc in noble is 1.75, so is affected.

And it's build with llvm 17, which is also affected.

what is the impact of llvm not producing proper backchain-saving logic?

[Zixing Liu (liushuyu-011)]

> Ok.

> rustc in noble is 1.75, so is affected.

> And it's build with llvm 17, which is also affected.

> what is the impact of llvm not producing proper backchain-saving logic?

The IBM Z system is funny because the backchain is inside the stack parameter region (reference: https://github.com/IBM/s390x-abi/blob/4e38ad9c8a883abc0ca248c2c6d51981ce7cbe02/lzsabi.tex#L2728), so if the backchain-saving logic is broken, the program itself is unaffected (since the parameter region will always have the backchain space, regardless of whether the backchain is enabled or not).

The worst-case scenario is that blockchain data is invalid or missing, which will affect debugging tools that do not understand `eh_frame` data (which is in DWARF format). According to IBM, at least on Linux systems, these tools are extremely rare on s390x.

[Steve Langasek (vorlon)]

ok, so it sounds like there are some known possibilities of regression here but that they are low impact and we're willing to accept those regressions as a trade-off.

[Zixing Liu (liushuyu-011)]

> ok, so it sounds like there are some known possibilities of regression here but that they are low impact and we're willing to accept those regressions as a trade-off.

Yes. Fixing the issue presents way more risks (e.g., breaking LLVM entirely, as we don't run tests for LLVM).

[Timo Aaltonen (tjaalton)]

Hello Zixing, or anyone else affected,

Accepted dpkg into noble-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/dpkg/1.22.6ubuntu6.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-noble to verification-done-noble. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-noble. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Ubuntu SRU Bot (ubuntu-sru-bot)]

All autopkgtests for the newly accepted dpkg (1.22.6ubuntu6.2) for noble have finished running.
The following regressions have been reported in tests triggered by the package:

autopkgtest/5.38ubuntu1~24.04.1 (amd64, arm64)
chrony/4.5-1ubuntu4.2 (arm64)
dgit/11.8 (ppc64el)
ding/1.9-7 (ppc64el)
gsequencer/6.5.2-1build3 (arm64)
haproxy/2.8.5-1ubuntu3.2 (s390x)
imagemagick/8:6.9.12.98+dfsg1-5.2build2 (ppc64el)
pkg-js-tools/0.15.18 (amd64, arm64, armhf, i386, ppc64el, s390x)
software-properties-qt/unknown (amd64, arm64, armhf, i386, ppc64el, s390x)
util-linux/2.39.3-9ubuntu6.1 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/noble/update_excuses.html#dpkg

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

[Zixing Liu (liushuyu-011)]

Verification done, see https://launchpadlibrarian.net/772222680/buildlog_ubuntu-noble-amd64.rust-ripgrep_14.1.0-1_BUILDING.txt.gz

[Andreas Hasenack (ahasenack)]

Hi Zixing Liu,

thanks for the verification. I fail to see how a link to a build log satisfies the test plan, though. Could you please elaborate on what you verified, and with which package(s) exactly?

Also, I would expect the verification to cover all architectures, and not just amd64.