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

[Koakuma]

Nathan Chancellor <nathan@xxxxxxxxxx> wrote:

> + 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@xxxxxxxxxxxxxxxxxxx> 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

Yes, at the moment LLD only has very basic capabilities and still can't link
the kernel, at least not without some rather invasive changes.
(And even if you manage to land all the changes to the kernel, still there are
many complex programs out there that's currently unlinkable by LLD that I feel
like improving LLD would be a better use of resources, in the long term)

As for the integrated assembler, now that PR 187534 [1] is merged it should
be possible to build the kernel with IAS, but that commit hasn't made it into
a release yet so I don't feel like it's the time to update the kernel's
docs... maybe?

[1]: https://github.com/llvm/llvm-project/pull/187534