objtool: bad .discard.annotate_insn

[sinatosk]

I was asked to report the issue here by nickdesaulniers from here related to llvm/llvm-project#195657. I posted to that existing issue as I thought it might be the same.

I'm using Gentoo Linux 2.18 and Linux 7.1-rc2 mainline with the following packages from Gentoo's repository

• GCC 15.2.1 - sys-devel/gcc-15.2.1_p20260214 stable
• GCC 16.1.0 - sys-devel/gcc-16.1.0 testing
• LLVM 22.1.4 - llvm-core/llvm-22.1.4 testing
• LLVM 22.1.5 - llvm-core/llvm-22.1.5 testing

recently LLVM 22.1.5 was released in Gentoo's testing repository and I included GCC 16.1.0 from testing repository.

I've tried the following with and without march/mtune set.

I've compiled Linux with LLVM 22.1.4 ( LLVM 22.1.4 at this point was compiled by GCC 15.2.1 ) but after upgrading to LLVM 22.1.5 ( LLVM 22.1.5 at this point was compiled by GCC 16.1.0 ) and compiling Linux with Clang 22.1.5 failed with the following errors

drivers/video/fbdev/core/fb.o: error: objtool: bad .discard.annotate_insn entry: 25 of type 8
make[6]: *** [scripts/Makefile.build:507: drivers/video/fbdev/core/fb.o] Error 255
make[6]: *** Deleting file 'drivers/video/fbdev/core/fb.o'
make[5]: *** [scripts/Makefile.build:548: drivers/video/fbdev/core] Error 2
make[4]: *** [scripts/Makefile.build:548: drivers/video/fbdev] Error 2
make[3]: *** [scripts/Makefile.build:548: drivers/video] Error 2
make[3]: *** Waiting for unfinished jobs....
drivers/gpu/drm/display/drm_display_helper.o: error: objtool: bad .discard.annotate_insn entry: 0 of type 8
make[6]: *** [scripts/Makefile.build:507: drivers/gpu/drm/display/drm_display_helper.o] Error 255
make[6]: *** Deleting file 'drivers/gpu/drm/display/drm_display_helper.o'
make[5]: *** [scripts/Makefile.build:548: drivers/gpu/drm/display] Error 2
make[4]: *** [scripts/Makefile.build:548: drivers/gpu/drm] Error 2
make[3]: *** [scripts/Makefile.build:548: drivers/gpu] Error 2
make[2]: *** [scripts/Makefile.build:548: drivers] Error 2
make[2]: *** Waiting for unfinished jobs....
arch/x86/kvm/kvm-amd.o: error: objtool: bad .discard.annotate_insn entry: 63 of type 7
make[4]: *** [scripts/Makefile.build:507: arch/x86/kvm/kvm-amd.o] Error 255
make[4]: *** Deleting file 'arch/x86/kvm/kvm-amd.o'
make[3]: *** [scripts/Makefile.build:548: arch/x86/kvm] Error 2
make[2]: *** [scripts/Makefile.build:548: arch/x86] Error 2
fs/smb/server/ksmbd.o: error: objtool: bad .discard.annotate_insn entry: 0 of type 8
make[5]: *** [scripts/Makefile.build:507: fs/smb/server/ksmbd.o] Error 255
make[5]: *** Deleting file 'fs/smb/server/ksmbd.o'
make[4]: *** [scripts/Makefile.build:548: fs/smb/server] Error 2
make[4]: *** Waiting for unfinished jobs....
sound/soc/dwc/designware_i2s.o: error: objtool: +0xdc5: special: can't find orig instruction
make[5]: *** [scripts/Makefile.build:507: sound/soc/dwc/designware_i2s.o] Error 255
make[5]: *** Deleting file 'sound/soc/dwc/designware_i2s.o'
make[4]: *** [scripts/Makefile.build:548: sound/soc/dwc] Error 2
make[3]: *** [scripts/Makefile.build:548: sound/soc] Error 2
make[2]: *** [scripts/Makefile.build:548: sound] Error 2
net/tls/tls.o: error: objtool: bad .discard.annotate_insn entry: 0 of type 8
make[4]: *** [scripts/Makefile.build:507: net/tls/tls.o] Error 255
make[4]: *** Deleting file 'net/tls/tls.o'
make[3]: *** [scripts/Makefile.build:548: net/tls] Error 2
make[3]: *** Waiting for unfinished jobs....
fs/nfs/nfs.o: error: objtool: bad .discard.annotate_insn entry: 0 of type 8
make[4]: *** [scripts/Makefile.build:507: fs/nfs/nfs.o] Error 255
make[4]: *** Deleting file 'fs/nfs/nfs.o'
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [scripts/Makefile.build:548: fs/nfs] Error 2
make[3]: *** Waiting for unfinished jobs....
fs/f2fs/f2fs.o: error: objtool: bad .discard.annotate_insn entry: 0 of type 8
make[4]: *** [scripts/Makefile.build:507: fs/f2fs/f2fs.o] Error 255
make[4]: *** Deleting file 'fs/f2fs/f2fs.o'
make[3]: *** [scripts/Makefile.build:548: fs/f2fs] Error 2
make[3]: *** [scripts/Makefile.build:548: fs/smb] Error 2
make[2]: *** [scripts/Makefile.build:548: net] Error 2
make[2]: *** [scripts/Makefile.build:548: fs] Error 2
make[1]: *** [/usr/src/linux-mainline/Makefile:2141: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2

So I downgraded to LLVM 22.1.4 ( at this point it was compiled by GCC 16.1.0 ) thinking it was a bug with LLVM 22.1.5 and it still failed with the same above errors which I thought was odd as I've compiled Linux mainline successfully with LLVM 22.1.4 before ( at that point LLVM 22.1.4 was compiled by GCC 15.2.1 ).

I downgraded GCC to 15.2.1 by

• Compiled GCC 15.2.1 using GCC 16.1.0
• Compiled LLVM 22.1.5 using GCC 15.2.1

and now Linux mainline successfully compiles with LLVM 22.1.5 ( Linux compiles with GCC 16.1.0 too ).

So I'm wondering if GCC 16.1.0 is compiling LLVM 22.1.4/22.1.5 incorrectly ( I've not tested LLVM lower than 22.1.4 )

At the time of this post, I'm now running Linux 7.1-rc2 compiled by LLVM 22.1.5 ( bootstrapped from GCC 15.2.1 ) from Linus's mainline at commit fcee7d82f27d6a8b1ddc5bbefda59b4e441e9bc0

[nickdesaulniers]

I wouldn't expect the bootstrapped compiler version (used to bootstrap the actual compiler) to make a difference like this (possible not impossible, but highly unlikely); that info might be a red herring here.

I suspect more likely your tree isn't clean or something was modified mid build. Can you share please your precise invocation of make when the build fails?

[sinatosk]

I always do a "make distclean" ( it's in the script ) before every kernel compile as I've had issues in the past.

every time I switch commit/branch from a git bisect or just switching to different kernel versions, I always

• backup kernel config
• make distclean
• switch branch/commit
• make distclean
• restore kernel config

takes longer but I've had less problems since then.

I do ( simplified but pretty much what's going on )

export LOCALVERSION=""

export KCFLAGS="-O2 -pipe -march=znver4 -mtune=znver4"
export KCPPFLAGS='${KCFLAGS}'
export KRUSTFLAGS="-Ctarget-cpu=znver4 -Ztune-cpu=znver4"

export INSTALL_MOD_STRIP='--strip-unneeded'

export INSTALL_HDR_PATH=/usr

export LLVM=1

nprocs=$(nproc)
export MAKEOPTS="-s -j${nprocs}"

make_target() {
    if [[ $# -ne 1 ]]; then
        echo make_target argument count invalid $#
        exit 1
    fi

    trgt=$1

    echo making target \"${trgt}\"

    time make ${MAKEOPTS} ${trgt}

    if [[ $? -ne 0 ]]; then
        echo target "${trgt}" failed...
        exit 1
    fi

    sync
}

cd /usr/src/linux-mainline

cp ./.config /usr/src/kernel_config.tmp

make distclean

cp /usr/src/kernel_config.tmp ./.config

make oldconfig

for trgt in vmlinux bzImage modules_prepare modules modules_install headers_install; do
    make_target "$trgt"
done

it fails during the "modules" target.

I usually do the git related stuff in other scripts.

it fails on line

time make ${MAKEOPTS} ${trgt}

which would expand to

time make -s -j16 modules

[nickdesaulniers]

--strip-unneeded looks non-standard, and I assume has something to do with section stripping. Seeing objtool complain about .discard.annotate_insn, I wonder if that is perhaps the smoking gun here. Can you retry your build without that set in order to eliminate (or confirm) that variable? Usually, adding flags on your own is a good way to wind up in untested territory.

[Arisa-Snowbell]

Having same problem, started with LLVM 22.1.4 from repos on Arch. No "--strip-unneeded" used

[nickdesaulniers]

ah, same error from both builds for from the same objtool referencing the same section. Sorry I missed that in the upstream report.

with LLVM 22.1.4 from repos on Arch.

Ah, we have seen issues in the past when distro's (in particular, Debian) change implicit default compiler flags, or carry downstream patches.

To rule that out, I would build Clang and friends from source at the release/22.x branch; if it's still reproducible, that rules out downstream changes. If not, then it's time to go ask the Arch LLVM maintainer what's up.

[nickdesaulniers]

@nathanchance maintains builds linked from https://mirrors.edge.kernel.org/pub/tools/llvm/. Those might be handy so that you don't have to build LLVM from source. They're also much much faster than most distro's builds, for building kernels.

[Arisa-Snowbell]

yeah the build from that link builds kernel fine

[sinatosk]

@nickdesaulniers,

the

export INSTALL_MOD_STRIP='--strip-unneeded'

is used during "modules_install" target and it strips symbols not needed for dynamic link and/or relocation resolution. There are debug symbols that are needed during compiling ( "vmlinux" and "modules" targets ) because of an option that's enabled ( I think it's related to BTF and/or BPF, don't remember exactly ) and the error fails during "modules" target which is before "modules_install" target.

Gentoo and Arch Linux use this flag too for the purpose of reducing the size of kernel modules otherwise they take up massive amount of space.

[computerix]

Similar problem here: https://bugzilla.kernel.org/show_bug.cgi?id=221460
Also Gentoo. But:

• This is a kernel build without any modules (CONFIG_MODULES is not set).
• The message happens only in the LTO phase of the kernel build, and only with thin or full LTO (no LTO works fine).

[sinatosk]

I'll add that I don't use LTO

here's my kernel .config which is used with LLVM 22.1.5 against linus mainline commit fcee7d82f27d6a8b1ddc5bbefda59b4e441e9bc0

This is configured to a Framework Laptop 16 with AMD 7840HS, no dGPU

[nathanchance]

So I'm wondering if GCC 16.1.0 is compiling LLVM 22.1.4/22.1.5 incorrectly ( I've not tested LLVM lower than 22.1.4 )

I suspect you may be on to something here. I have been unable to reproduce this issue with the kernel.org version of LLVM 22.1.5 (which is build with clang 22.1.5 in a multi-stage configuration) with any of the configurations provided but it does reproduce with Arch Linux's LLVM 22.1.5 (built with GCC 16.1.1) using both @computerix and @sinatosk's configurations.

$ readelf -p.comment /usr/bin/{clang-22,ld.lld}

File: /usr/bin/clang-22

String dump of section '.comment':
  [     0]  GCC: (GNU) 16.1.1 20260430


File: /usr/bin/ld.lld

String dump of section '.comment':
  [     0]  GCC: (GNU) 16.1.1 20260430

$ curl -LSso .config https://github.com/user-attachments/files/27516248/kernel.config.txt

$ scripts/config -u MODULE_SIG_KEY

$ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 olddefconfig all
drivers/bus/mhi/host/mhi.o: error: objtool: bad .discard.annotate_insn entry: 0 of type 1
...
drivers/video/fbdev/core/fb.o: error: objtool: bad .discard.annotate_insn entry: 25 of type 8
...

If I downgrade to LLVM 22.1.3, which was built with GCC 15.2.1, the build completes successfully. I don't believe Arch patches LLVM, at least not in the way that Debian has (it is usually just upstream cherry-picks for issues it has noticed).

I will see if I can reproduce this by building GCC from source then building LLVM then the kernel so that I can potentially bisect it and report it to the GCC developers.

[sinatosk]

Just thought I would add this as I started this process nearly 3 hours ago and was typing this as I was waiting for the compiles to complete. sorry if it's a bit repetitive.

• glibc 2.42 - sys-libs/glibc-2.42-r5 stable

In case I thought it was a bit flip or something, I decided to recompile LLVM 22.1.5 again using GCC 16.1.0, also recompiled glibc 2.42 using GCC 15.2.1 as glibc 2.42 was compiled using GCC 16.1.0 ( now as of the writing of this post glibc 2.42 is compiled by GCC 15.2.1 ) and the errors are there again ( both before and after recompiling glibc )

I've recompiled LLVM 22.1.5 using GCC 15.2.1 ( at this point glibc 2.42 is compiled by GCC 15.2.1 ) and no warnings/errors when compiling Linux usnig LLVM at this point.

What I'm saying here about Arch Linux is a guess

looking at Arch Linux package update history for GCC and LLVM, they've compiled LLVM 22.1.3 using GCC 15.2.1 and I'm guessing that's why LLVM 22.1.3 worked for @Arisa-Snowbell and not 22.1.4 as it looks like they compiled it using GCC 16.1.1 ( not 16.1.0 ).

I'm starting to lean a bit towards this is a bug in GCC 16.1 on how it's compiling LLVM 22.1.4 and 22.1.5