[Bug] Kernel builds with x86-64-v2 but host tools (objtool, fixdep, etc.) require x86-64-v3

[udosan174]

I encountered an issue when building the kernel with x86-64-v2 settings.
The kernel itself builds and runs fine, but several host tools (such as objtool, fixdep, modpost, resolve_btfids, etc.) are generated with a .note.gnu.property section that declares "ISA needed: x86-64-v3".

This causes a problem on CPUs that only support x86-64-v2:

• The kernel image works correctly.
• However, DKMS fails when trying to build external modules, because these host tools cannot run on v2-only hardware.

Steps to reproduce:

1. Build the kernel with _config=config_x86-64-v2 (or equivalent -march=x86-64-v2).
2. Inspect tools/objtool/objtool with readelf -n.
3. The output shows ISA needed: x86-64-v3.

Build environment:

• CPU: AMD Zen3
• Compiler: Clang
• LTO mode: Full LTO

Expected behavior:

• Host tools should match the selected ISA level (v2 in this case), so that DKMS and external module builds remain functional on v2 hardware.

Actual behavior:

• Host tools require x86-64-v3 even when the kernel is built for x86-64-v2.

Impact:

• DKMS cannot build modules on v2-only CPUs, making kernel customization impossible in such environments.

Workaround:

• Manually stripping the .note.gnu.property section from host tools after build resolves the issue, for example:
  strip --remove-section=.note.gnu.property ./tools/objtool/objtool
• While this workaround allows DKMS to function, it is not a sustainable solution.

Could you please review the build flags or toolchain settings for host tools so they respect the selected ISA level?

[oxyzenQ]

Short diagnosis

• The kernel itself is being built for x86-64-v2, but some host tools (objtool, fixdep, modpost, etc.) were compiled in a way that embeds a .note.gnu.property declaring “ISA needed: x86-64-v3”.
• Most likely cause: the host tool build used host-default compiler flags (e.g., -march=native on your Zen3 build machine) or LTO/clang behavior that embeds the host ISA requirement in the produced binaries. Those host tools therefore cannot run on v2-only machines even though the kernel image is compatible.

What you can try locally

1. Quick workaround (already mentioned in the issue)

• Strip the note after build:
  • objcopy --remove-section .note.gnu.property ./tools/objtool/objtool
  • or strip --remove-section=.note.gnu.property ./tools/objtool/objtool
• Pros: quick and effective; Cons: manual, not ideal for reproducible builds.

2. Force host tools to compile for the lower ISA

• Explicitly set host compiler flags so host tools are built targeting v2 (do this on the machine where you build the kernel):
  • Add host compiler flags that disable ISA extensions (example conceptually):
    • HOSTCFLAGS="-march=x86-64-v2" HOSTCXXFLAGS="-march=x86-64-v2"
  • Or export them in the environment before invoking make.
• Exact variable names accepted by the kernel build can vary across trees; common approaches:
  • Pass HOSTCFLAGS or HOSTEXTRA_CFLAGS (try echoing make help or checking top-level Makefile to confirm the right host-flag variable in this repo).
  • If you use clang/LLVM, ensure you pass the equivalent -mattr or -march flags to clang for host builds.
• Pros: produces host tools that run on v2 machines; Cons: you must ensure flags are applied to all host-tool compilation units.

3. Avoid propagating -march=native from your build host

• If your host environment or distro build system supplies -march=native by default, unset that or override it when building the kernel so host-tool compilation won’t pick up v3-only ISA.

4. Disable/limit LTO for host tools

• Full LTO sometimes causes cross-contamination of properties. If you’re using full LTO for the kernel, try disabling LTO or limiting it to kernel objects only (so host tools are built without LTO).
• Rebuild with LTO off (or a different LTO setting) and check the .note again.

5. Reproduce and verify

• After changing flags, rebuild the host tool and run:
  • readelf -n tools/objtool/objtool
• Confirm the .note.gnu.property no longer declares x86-64-v3.

[1Naim]

Steps to reproduce:

1. Build the kernel with `_config=config_x86-64-v2` (or equivalent `-march=x86-64-v2`).

Sorry, what is this? There is nothing called _config in linux-cachyos much less any config value config_x86-64-v2. Anyway, I built a v2 kernel on a Zen4 CPU and I cannot reproduce this.

❯ readelf -n tools/objtool/objtool 

Displaying notes found in: .note.gnu.property
  Owner                Data size        Description
  GNU                  0x00000010       NT_GNU_PROPERTY_TYPE_0
      Properties: x86 ISA needed: x86-64-baseline

❯ grep "X86_64_VERSION" .config
CONFIG_X86_64_VERSION=2

[udosan174]

Build Environment

• CPU: Zen3
• Kernel: linux-cachyos
• Repository: cachyos_v3

Build Target

• Package: linux-cachyos-rt-bore

PKGBUILD Changes
: "${_processor_opt:=GENERIC_V2}"
: "${_use_llvm_lto:=full}"

Config (config-6.17.8-1-cachyos-rt-bore-lto
　# CONFIG_X86_NATIVE_CPU is not set
　CONFIG_GENERIC_CPU=y
　# CONFIG_MZEN4 is not set
　CONFIG_X86_64_VERSION=2

Issue
The kernel itself is correctly built for x86-64-v2, but host tools such as objtool are unexpectedly built requiring x86-64-v3.
Example:

$ readelf -n src/linux-6.17.8/tools/objtool/objtool

Displaying notes found in: .note.gnu.property
Owner Data size Description
GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0
Properties: x86 ISA needed: x86-64-baseline, x86-64-v2, x86-64-v3

Question
Where should this be fixed so that host tools respect the selected ISA level (x86-64-v2) instead of requiring x86-64-v3?

[1Naim]

Okay, it looks like building these tools are using CFLAGS in /etc/makepkg.conf. If you change -march=native to -march=x86-64-v2, it should fix it.

[udosan174]

Unfortunately, my /etc/makepkg.conf is as follows.

CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"

#-- Compiler and Linker Flags
#CPPFLAGS=""
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection"

[1Naim]

Are you sure you have nothing in /etc/makepkg.conf.d or something like /etc/makepkg-optimize.conf? If yes then please attach a verbose build log of the kernel.

Thanks.

[udosan174]

I created a new makepkg.conf based on makapkg.conf.pacnew and tried building with -march=x86-64-v2, but the situation did not change.
If more detailed build logs are required, please provide instructions on how to obtain them.

linux-cachyos-rt-bore-lto-6.17.8-1-x86_64-build.log
PKGBUILD.txt
makepkg.conf.txt
config-6.17.8-1-cachyos-rt-bore-lto.txt

[ptr1337]

Can you try to build in chroot?

sudo pacman -S devtools
pkgctl build

[udosan174]

I couldn’t access my development environment for a while, so my reply was delayed.
"pkgctl build" worked and the build completed successfully. Thanks.