RISC-V unsupported version number ... for extension '...'

[nathanchance]

The kernel test robot recently reported a series of ARCH=riscv link errors when using ld.lld and GNU as that appear after a backport of mine. Looking into it further, these are visible in mainline when using recent binutils (I see it with 2.39):

$ make -skj"$(nproc)" ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- LLVM=1 LLVM_IAS=0 defconfig all
ld.lld: error: arch/riscv/kernel/vdso/rt_sigreturn.o:(.riscv.attributes): rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicbom1p0_zicsr2p0_zihintpause2p0: unsupported version number 2.1 for extension 'i'
ld.lld: error: arch/riscv/kernel/vdso/vgettimeofday.o:(.riscv.attributes): rv64i2p0_m2p0_a2p0_c2p0_zicbom1p0_zicsr2p0_zifencei2p0_zihintpause2p0: unsupported version number 2.0 for extension 'zicsr'
ld.lld: error: arch/riscv/kernel/vdso/getcpu.o:(.riscv.attributes): rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicbom1p0_zicsr2p0_zihintpause2p0: unsupported version number 2.1 for extension 'i'
ld.lld: error: arch/riscv/kernel/vdso/flush_icache.o:(.riscv.attributes): rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicbom1p0_zicsr2p0_zihintpause2p0: unsupported version number 2.1 for extension 'i'
ld.lld: error: arch/riscv/kernel/vdso/note.o:(.riscv.attributes): rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_zicbom1p0_zicsr2p0_zihintpause2p0: unsupported version number 2.1 for extension 'i'
...
ld.lld: error: net/8021q/vlan.o:(.riscv.attributes): rv64i2p0_m2p0_a2p0_c2p0_zicbom1p0_zicsr2p0_zifencei2p0_zihintpause2p0: unsupported version number 2.0 for extension 'zicsr'
ld.lld: error: net/8021q/vlan_dev.o:(.riscv.attributes): rv64i2p0_m2p0_a2p0_c2p0_zicbom1p0_zicsr2p0_zifencei2p0_zihintpause2p0: unsupported version number 2.0 for extension 'zicsr'
ld.lld: error: net/8021q/vlan_netlink.o:(.riscv.attributes): rv64i2p0_m2p0_a2p0_c2p0_zicbom1p0_zicsr2p0_zifencei2p0_zihintpause2p0: unsupported version number 2.0 for extension 'zicsr'
ld.lld: error: net/8021q/vlanproc.o:(.riscv.attributes): rv64i2p0_m2p0_a2p0_c2p0_zicbom1p0_zicsr2p0_zifencei2p0_zihintpause2p0: unsupported version number 2.0 for extension 'zicsr'
...

We do not test LLVM=1 LLVM_IAS=0 much in newer kernels and CI's version of binutils is not new enough to show this.

[ConchuOD]

@nathanchance FWIW for binutils it was decided that this was not worth caring about:
bminor/binutils-gdb@87fdd7ac09b

What version of LLVM is this with?

[nathanchance]

@ConchuOD I believe this was with tip of tree at the time, so 16.

[ConchuOD]

@nathanchance I was hoping it'd be an earlier version :(

I'm really not sure what to do about these, last time around (with zihintpause/zicbom) it wasn't immediately obvious how one is meant to check what extensions (or versions thereof) the linker supported since there was seemingly no way to pass the isa string to the linker to test what it was capable of.

That's why we settled for LD version checks in Kconfig for enabling extensions, eg:

config TOOLCHAIN_HAS_ZICBOM
	bool
	default y
	depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zicbom)
	depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zicbom)
	depends on LLD_VERSION >= 150000 || LD_VERSION >= 23800

Ditto for Zihintpause.

23800 predates Zicbom support, but is the version of ld that contained bminor/binutils-gdb@87fdd7ac09b ;)

We, AFAIK, don't pass --with-spec-version so you get whatever the defaults for your toolchain are. @palmer-dabbelt probably knows far more than I do about what's doable (or if anything is even worth doing about this)

We do not test LLVM=1 LLVM_IAS=0 much in newer kernels

I test these sort of things for patchsets adding instructions that require toolchain support, got a bunch of setups that I try.
But I don't touch it in my CI or in the patchwork automation stuff.

[asb]

We consider this to be a regression in LLD, and an unintended side-effect of using RISCVISAInfo.cpp to aid in the logic for build attribute merging. See llvm/llvm-project#60889 and my related post on LLVM discourse. Sorry for the hassle here - if you encounter problems like this in the future, please do tag me or even better, file an upstream bug.

[nathanchance]

@asb Thanks a lot for pointing out those issues, I will make sure not to sit on future reports for that long, I did not consider bisecting LLVM to see if it was a recent change that caused this.

[asb]

No need to bisect if you see something that looks like a usability problem for gcc/clang compatibility. Even if it's not a regression, we're keen to fix it! Looks like it's confirmed there'll be a 16.0.0-rc4 so there's still hope we can get the fix in to 16.0.0 if it gets reviewed quickly.

[asb]

My patch to resolve this in LLD is now reviewed and committed, and I've requested a backport to the 16.0.0 release branch, meaning 16.0.0 hopefully won't have this issue.

[nickdesaulniers]

@nathanchance (or @ConchuOD ) can you re-verify this then close this out if we're all set here?

[ConchuOD]

@nathanchance (or @ConchuOD ) can you re-verify this then close this out if we're all set here?

Checking it was on my plan for today, I'll do it once I've had lunch!

[ConchuOD]

@nathanchance (or @ConchuOD ) can you re-verify this then close this out if we're all set here?

Checking it was on my plan for today, I'll do it once I've had lunch!

CONFIG_CC_VERSION_TEXT="ClangBuiltLinux clang version 16.0.0 (/stuff/toolchains/llvm/clang f53ab957ead2cba674e72c22dcbd0cd74007940a)"
CONFIG_GCC_VERSION=0
CONFIG_CC_IS_CLANG=y
CONFIG_CLANG_VERSION=160000
CONFIG_AS_IS_GNU=y
CONFIG_AS_VERSION=23900
CONFIG_LD_VERSION=0
CONFIG_LD_IS_LLD=y
CONFIG_LLD_VERSION=160000

The above built a defconfig kernel for me fine.

[ConchuOD]

@nathanchance @nickdesaulniers I think we can close this one?