Files
kernel-agent/patches/arch/arm64/xor-neon-ffixed-x18-scs-build-fix-danctnix/0001-arm64-xor-neon-ffixed-x18-build-fix.patch
T
claude-noether f203b70f4f fleet/ohm: switch bes2600 driver scope to cumulative-c5x-danctnix interim (closes #5 partial migration)
Audit during ohm pkgrel=4 migration found the per-series -danctnix
mirrors merged in #17 do NOT apply against the linux-pinetab2 baseline:
all 17 of them use DKMS-style root paths (bes2600/foo.c) rather than
in-tree staging paths (drivers/staging/bes2600/foo.c), and at least one
has a corrupted mixed-prefix header
(a/drivers/staging/bes2600/...  b/bes2600/...).

ka-promote ohm with those includes produced a 172 644-byte cumulative
touching 27 file paths, of which 11 are bogus. The hand-curated
0001-bes2600-besser-cumulative-series.patch from the working
danctnix-besser-pkgbuild flow on boltzmann (148 149 bytes, 48 in-tree
staging files) is what pkgrel=3 actually builds with.

Until the per-series mirrors are reconstructed (followup issue to be
opened separately), the bes2600 driver scope is satisfied here by
staging that hand-curated cumulative as a single-file series-dir
patches/driver/bes2600/cumulative-c5x-danctnix/. ohm.yaml drops the
broken per-series includes in favour of:

  - driver/bes2600/cumulative-c5x-danctnix/
  - driver/bes2600/scan-filter-5ghz-danctnix/      (closes besser#1)
  - arch/arm64/xor-neon-ffixed-x18-scs-build-fix-danctnix/

ka-promote ohm now produces a self-consistent 157 446-byte cumulative
(148 149 + 7 735 + 1 562 = exact byte arithmetic) with b2sum
a807297b25be... which is what the new
marfrit-packages/arch/linux-pinetab2-danctnix-besser PKGBUILD pkgrel=4
pins.

Also fixes fleet/ohm.yaml YAML parse error: bar5_burn_in had a scalar
value followed by a sub-list, which ka-promote (PyYAML) refused to
parse. The whole manifest had never parsed cleanly since #18 landed.

Refs: #5 (migrate PKGBUILD), #2 (mirror besser series — needs per-series
rewrite followup), besser#1 (Patch I).
2026-05-18 16:50:41 +02:00

37 lines
1.5 KiB
Diff

From: Markus Fritsche <fritsche.markus@gmail.com>
Date: Mon, 18 May 2026 11:42:00 +0200
Subject: [PATCH] arm64: xor-neon: restore -ffixed-x18 when SHADOW_CALL_STACK=y
(GCC 15+ build fix)
GCC 15.2.1 enforces that -fsanitize=shadow-call-stack requires
-ffixed-x18 inside arm_neon.h's #pragma GCC target() blocks. The
existing CFLAGS_REMOVE_xor-neon.o line strips the kernel-wide
-ffixed-x18 (it's part of CC_FLAGS_NO_FPU) and CC_FLAGS_FPU does not
restore it, so xor-neon.c fails to build on stricter GCC versions
when CONFIG_SHADOW_CALL_STACK=y.
Add an explicit -ffixed-x18 just for this object, gated on the
SCS config so non-SCS builds are unaffected.
Build environment workaround; not a kernel-runtime bug.
---
arch/arm64/lib/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/lib/Makefile b/arch/arm64/lib/Makefile
index 1234567..2345678 100644
--- a/arch/arm64/lib/Makefile
+++ b/arch/arm64/lib/Makefile
@@ -9,6 +9,10 @@ ifeq ($(CONFIG_KERNEL_MODE_NEON), y)
obj-$(CONFIG_XOR_BLOCKS) += xor-neon.o
CFLAGS_xor-neon.o += $(CC_FLAGS_FPU)
CFLAGS_REMOVE_xor-neon.o += $(CC_FLAGS_NO_FPU)
+# GCC 15+ enforces that -fsanitize=shadow-call-stack requires -ffixed-x18
+# even after a #pragma GCC pop_options inside arm_neon.h. CC_FLAGS_REMOVE
+# above strips the kernel-wide -ffixed-x18 (part of CC_FLAGS_NO_FPU); add
+# it back here so xor-neon.c still compiles when SHADOW_CALL_STACK=y.
+CFLAGS_xor-neon.o += $(if $(CONFIG_SHADOW_CALL_STACK),-ffixed-x18)
endif
lib-$(CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE) += uaccess_flushcache.o