Building the kernel fails. Reproducible: Always Steps to Reproduce: 1. emerge =sys-kernel/gentoo-kernel-6.13.1 Actual Results: arch/x86/tools/insn_decoder_test: error: malformed line 4113078: 2_>:ffffffff81dcc160 Expected Results: Built kernel. Tried with -experimental and my config.d stuff removed. Same results. 9800X3D is my CPU. I was able to build 6.12.12 successfully today as well. It appears to be something in some rust DRM stuff (checking objdump of vmlinux, I'm on dev-lang/rust-1.84.0 if that matters.
Created attachment 918086 [details] build log
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/tools/insn_decoder_test.c?h=v6.13.1#n109 <__pfx__RNCINvNtNtNtCsilVJiKMIQzN_4core4iter8adapters3map12map_try_foldjNtCsl7NWQAmDYli_12drm_panic_qr7VersionuINtNtNtBa_3ops12control_flow11ControlFlowB10_ENcB10_0NCINvNvNtNtNtB8_6traits8iterator8Iterator4find5checkB10_NCNvMB12_B10_13from_segments0E0E0B12_>:ffffffff81dcc160 that line from objdump is over 256 bytes
I tried to reproduce this while on #gentoo with the same compiler version ebuild gentoo-kernel-6.13.1.ebuild clean compile ebuild gentoo-kernel-6.13.1.ebuild install Various combinations of USE flags enabled except savedconfig or secureboot I could not reproduce the error on full ~amd64 system
Portage 3.0.67 (python 3.12.8-final-0, default/linux/amd64/23.0/desktop/plasma/systemd, gcc-14, glibc-2.40-r8, 6.12.12-gentoo-dist x86_64) ================================================================= System uname: Linux-6.12.12-gentoo-dist-x86_64-AMD_Ryzen_7_9800X3D_8-Core_Processor-with-glibc2.40 sh bash 5.2_p37 ld GNU ld (Gentoo 2.43 p3) 2.43.1 app-misc/pax-utils: 1.3.8::gentoo app-shells/bash: 5.2_p37::gentoo dev-build/autoconf: 2.13-r8::gentoo, 2.71-r7::gentoo, 2.72-r1::gentoo dev-build/automake: 1.17-r1::gentoo dev-build/cmake: 3.31.5::gentoo dev-build/libtool: 2.5.4::gentoo dev-build/make: 4.4.1-r100::gentoo dev-build/meson: 1.7.0::gentoo dev-java/java-config: 2.3.4::gentoo dev-lang/perl: 5.40.0-r1::gentoo dev-lang/python: 3.12.8_p1::gentoo dev-lang/rust: 1.84.0::gentoo llvm-core/clang: 18.1.8-r6::gentoo, 19.1.7::gentoo llvm-core/lld: 18.1.8::gentoo, 19.1.7::gentoo llvm-core/llvm: 18.1.8-r6::gentoo, 19.1.7::gentoo sys-apps/baselayout: 2.17::gentoo sys-apps/sandbox: 2.43::gentoo sys-apps/systemd: 257.2::gentoo sys-devel/binutils: 2.43-r2::gentoo sys-devel/binutils-config: 5.5.2::gentoo sys-devel/gcc: 14.2.1_p20241221::gentoo sys-devel/gcc-config: 2.12.1::gentoo sys-kernel/linux-headers: 6.12::gentoo (virtual/os-headers) sys-libs/glibc: 2.40-r8::gentoo
RUSTFLAGS=" -C target-cpu=native -C opt-level=3" my rust flags in case they're somehow affecting things (it is a symbol from rust code causing insn_decoder_test to misbehave)
https://bugzilla.kernel.org/show_bug.cgi?id=219729
(In reply to Michael Cook from comment #5) > RUSTFLAGS=" -C target-cpu=native -C opt-level=3" > > > my rust flags in case they're somehow affecting things (it is a symbol from > rust code causing insn_decoder_test to misbehave) I suspect having target-cpu=native in there is "wrong" and that this is the same as the "-march=native" stuff where a bunch of Makefiles have to then pass -mno-avx or whatever and so on because objtool can't decode various instructions (nor are they actually correct to use in kernel context b/c of SIMD save/restore).
... but ah, I see the upstream bug, so ignore me, but I'd still consider this a possible problem in the future nonetheless for kernel builds w/ Rust enabled.
https://gitlab.com/cki-project/kernel-ark/-/commit/8d4a52c3921d278f27241fc0c6949d8fdc13a7f5 Fedora's patch
If H.J. approves of it, it's fine for us IMO.
I can confirm a successful build with the patch.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8a44892e05dc7f3b06a2b8c77a003945affd0c40 commit 8a44892e05dc7f3b06a2b8c77a003945affd0c40 Author: Mike Pagano <mpagano@gentoo.org> AuthorDate: 2025-02-08 11:51:23 +0000 Commit: Mike Pagano <mpagano@gentoo.org> CommitDate: 2025-02-08 11:52:57 +0000 sys-kernel/gentoo-sources: add 6.13.2, insn_decoder_test length fix x86/insn_decoder_test: allow longer symbol-names Bug: https://bugs.gentoo.org/949240 Signed-off-by: Mike Pagano <mpagano@gentoo.org> sys-kernel/gentoo-sources/Manifest | 3 ++ .../gentoo-sources/gentoo-sources-6.13.2.ebuild | 37 ++++++++++++++++++++++ 2 files changed, 40 insertions(+)
