Skip to content

kexec-tools: Only force ELFv2 on ppc64 when the platform settings aggree #422007

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
flokli merged 1 commit into from
Jul 29, 2025
+7 −5
Merged

kexec-tools: Only force ELFv2 on ppc64 when the platform settings aggree #422007

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 7 additions & 5 deletions pkgs/by-name/ke/kexec-tools/package.nix
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,17 +23,19 @@ stdenv.mkDerivation rec {
};

patches = [
# Use ELFv2 ABI on ppc64be
(fetchpatch {
url = "https://raw.githubusercontent.com/void-linux/void-packages/6c1192cbf166698932030c2e3de71db1885a572d/srcpkgs/kexec-tools/patches/ppc64-elfv2.patch";
sha256 = "19wzfwb0azm932v0vhywv4221818qmlmvdfwpvvpfyw4hjsc2s1l";
})
# Fix for static builds, will likely be removable on the next release
(fetchpatch {
url = "https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/patch/?id=daa29443819d3045338792b5ba950ed90e79d7a5";
hash = "sha256-Nq5HIcLY6KSvvrs2sbfE/vovMbleJYElHW9AVRU5rSA=";
})
]
++ lib.optionals (stdenv.hostPlatform.isPower64 && stdenv.hostPlatform.isAbiElfv2) [

@SuperSandro2000 SuperSandro2000 Jul 28, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to make the patch optional? The next person updating the package might easily miss this to the disadvantage of powerpc users.

@OPNA2608 OPNA2608 Jul 28, 2025 •
edited
Loading

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With this patch file? Yes, because it breaks building for ELFv1 (which, eventually, I'm planning to make our default ABI on powerpc64, because it's less effort to get it to work properly). Doing this in a way that supports both ABI would require a custom patch, because upstream currently doesn't support different flags for different ABI targets.

@flokli flokli Jul 29, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We usually don't do conditional patches, because they end up breaking easily without being noticed during regular package bumps.

We're less strict for more "exotic" targets/platforms, see this example:

nixpkgs/pkgs/os-specific/linux/systemd/default.nix

Line 257 in 349024c

++ lib.optionals stdenv.hostPlatform.isMusl (

I think it's fine to pull it in conditionally, cause power64 is also somewhat niche, but I strongly recommend to start upstreaming this in a more generic fashion to avoid this breaking in the future.

@flokli flokli Jul 29, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, because it breaks building for ELFv1 (which, eventually, I'm planning to make our default ABI on powerpc64, because it's less effort to get it to work properly).

Isn't elfv1 marked as legacy? (see rust-lang/rust#60617)

@OPNA2608 OPNA2608 Jul 29, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ELFv1 is considered legacy, but big-endian 64-bit POWER itself is kind of legacy too. Modern 64-bit POWER processors are usually run in little-endian mode, where ELFv2 is (IIRC) the only supported ABI. But 64-bit POWER started out as big-endian in Linux, ELFv1 was the current version for most of its lifetime, and glibc still defaults to ELFv1 unless explicitly told otherwise, so it's still the "default".

The ABI situation of powerpc64 in the libc's is as follows:

  • glibc supports either ABI version, but defaults to ELFv1 unless specifically told otherwise
  • musl only supports ELFv2

Certain (bad) assumptions have developed like ~ "on 64-bit POWER, the ABI is ELFv2 on LE and ELFv1 on BE". Patches like the one that gets shuffled around in this PR come mostly from musl-running distros - Void PPC when it was still around, Adelie Linux, Chimera Linux are all musl distros that I used to look towards for ELFv2 patches. All glibc-using distros supported powerpc64 that I could find (Debian, Gentoo) use the ELFv1 ABI that glibc defaults to. Some (Gentoo IIRC) attempted to switch their glibc to ELFv2 in the past, but it looks like they're still on ELFv1 as of today.

I gave up on ELFv2 when I got to Valgrind. I was unable to get it to accept & properly handle ELFv2 binaries produced by Nix, unless I built them against musl and used patchelf to replace our musl in the final binary with i.e. Adelie's musl. So either something is missing in the ELFv2 patch, or our toolchain just uniquely breaks Valgrind. The ELFv2 MR has been dormant for awhile upstream, so I'm not too optimistic about this support becoming official soon. In contrast, ELFv1 Valgrind has worked just fine.

There are more issues with ELFv2 on powerpc64. Most prebuilt binaries target ELFv1, so i.e. bootstrapping Rust, GHC etc gets more annoying, and would require cross-compilation between ABIs or something weird like that. I know Adelie has their own prebuilt, prepatched Rust toolchain artefacts on their GitLab instance that they use for Rust things. I imagine that those might not just magically work for us though. With GHC, I'm even less sure about the state of ELFv2 support. All of these issues naturally go away when we don't force ELFv2.

So in short, yes it's legacy, but it Just Works ™️, and is the path of least resistance on this platform.

# Use ELFv2 ABI on ppc64be
(fetchpatch {
url = "https://raw.githubusercontent.com/void-linux/void-packages/6c1192cbf166698932030c2e3de71db1885a572d/srcpkgs/kexec-tools/patches/ppc64-elfv2.patch";
sha256 = "19wzfwb0azm932v0vhywv4221818qmlmvdfwpvvpfyw4hjsc2s1l";
})
]
++ lib.optional (stdenv.hostPlatform.useLLVM or false) ./fix-purgatory-llvm-libunwind.patch;

hardeningDisable = [
Expand Down
Loading