Re: [PATCH] sparc: Avoid unsupported LLD branch relocations

[Nathan Chancellor <nathan@kernel.org>]

+ Koakuma

On Wed, May 13, 2026 at 10:34:44PM -0700, Rosen Penev wrote:
> On Wed, May 13, 2026 at 10:03 PM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> >
> > Hi Rosen,
> >
> > On Wed, 2026-05-13 at 21:19 -0700, Rosen Penev wrote:
> > > LLD does not support several SPARC branch relocation types, including
> > > R_SPARC_WDISP16, R_SPARC_WDISP19, and R_SPARC_WDISP22. A sparc64
> > > allmodconfig LLVM build can therefore fail when trap table code and
> > > low-level assembly leave branches to global symbols for the linker.
> > >
> > > Use local labels for branches that stay within the same assembled
> > > object so the assembler can resolve them directly. Convert the
> > > remaining cross-object branches and tail calls to absolute set/jmpl
> > > sequences, which LLD handles through the usual HI22/LO10 relocations.
> > >
> > > Disable the unused sparc32 syscall trace entry points when compat
> > > support is not built, and request sys_llseek for the native syscall
> > > table so the LLD allmodconfig build remains self-contained.
> >
> > I would rather fix LLD than making such intrusive changes to the SPARC
> > code in the kernel. In particular, since this touches the CPU-optimized
> > memory routines which had been haunted by subtle bugs for years and were
> > only fixed recently.
> >
> > Is improving LLD in this case not possible?
> Above my paygrade. I use this so that allmodconfig succeeds.

We document sparc64 as only having support for clang as the compiler
(not even supporting the integrated assembler yet, although maybe that
needs to be updated [1]?) in Documentation/kbuild/llvm.rst, so I don't
think we should take a patch like this. As far as I am aware, ld.lld
work for sparc64 has not happened yet to make it work with the kernel.
If you need to test with clang, use CC=clang LLVM_IAS=0 with GNU
binutils (CROSS_COMPILE=sparc64-linux-gnu-).

[1]: https://github.com/llvm/llvm-project/issues/40792

-- 
Cheers,
Nathan