linux-kernel - Re: [PATCH v1 1/2] LoongArch: Make LTO case independent in Makefile

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250923011057.GA3980504@ax162>
Date: Mon, 22 Sep 2025 18:10:57 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Tiezhu Yang <yangtiezhu@...ngson.cn>
Cc: Huacai Chen <chenhuacai@...nel.org>, Miguel Ojeda <ojeda@...nel.org>,
	WANG Rui <wangrui@...ngson.cn>, rust-for-linux@...r.kernel.org,
	loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org,
	llvm@...ts.linux.dev
Subject: Re: [PATCH v1 1/2] LoongArch: Make LTO case independent in Makefile

> > > ifdef CONFIG_LTO_CLANG
> > > ifdef CONFIG_LLD_HAS_ANNOTATE_TABLEJUMP
> > > KBUILD_LDFLAGS                  += -mllvm --loongarch-annotate-tablejump
> > > else
> > > KBUILD_LDFLAGS                  += -mllvm --no-jump-tables
> > > endif

There is no '--no-jump-tables' LLVM option so this will not work.
Shouldn't -fno-jump-tables and -Zno-jump-tables take care of generating
jump tables?

> I do not know whether this is valid, you can test it with llvm 18
> and llvm 20 if you think it is a proper way.

For what it's worth, Huacai's original suggestion of

    KBUILD_LDFLAGS += $(call ld-option,-mllvm --loongarch-annotate-tablejump)

appears to work for me and I do not see any objtool warnings with LTO
enabled but I might be missing something.

> But IIRC, there is objtool warning with llvm 18, I reported to llvm
> developer Wang Lei and he fixed it as the following commit:
> 
> [LoongArch] Avoid indirect branch jumps using the ra register
> https://github.com/llvm/llvm-project/commit/21ef17c62645
> 
> Actually, the above commit solved a performance issue of llvm compiler,
> so I prefer to update the minimal llvm version to 20 for LoongArch.

I tend to let architecture maintainers make the call around minimum
supported versions of compilers, so if that is how you would like to
proceed, I am fine with that. I will say LLVM 20 is pretty new (released
on March 4th, 2025) but I expect most of your users to probably be using
bleeding edge tools for all the changes you make in the compiler and
lower level libraries?

Cheers,
Nathan