Fw: Re: [PATCH 0/3] ld: shared library and PIE support for riscv*-elf and loongarch*-elf

[mintsuki]

On Tuesday, September 8th, 2026 at 4:33 PM, Xi Ruoyao <xry111@xry111.site> wrote:

> On Fri, 2026-09-04 at 17:34 +0000, mintsuki wrote:
> > > No. This is useful for other things than PE executables.
> > >
> > > The LLM wrote that and I didn't bother to correct it because the
> > > patches stand on their own merit.
> 
> IMO you should fix it (or simply delete it if you really don't care it).
> Sending LLM output to reviewers w/o reviewing it first just adds extra
> burdens to them.

I did read it, I just didn't think it would become a central focus of the
discussion. Sorry for the carelessness as I should've foreseen eyebrows
being raised at the PE/EFI arguments.

I will resend the whole patchset, this time with a proper reply chain and
the sections mentioning PE/EFI removed.

> 
> > > Someone wanting to use a riscv64-elf or loongarch64-elf toolchain
> > > to make a PIE kernel/freestanding application (ELF) (that the
> > > Limine bootloader can load just fine) will encounter this error,
> > > and, as far as I can tell, there isn't a good reason not to let
> > > these freestanding toolchains for these architectures generate
> > > PIEs/shared.
> 
> The kernel should be a static PIE instead of shared object.  The current
> RISC-V Linux relocatable kernel is linked with -shared but IMO it's
> wrong.
> 
> I pointed this out when I reviewed the patch adding relocatable support
> to LoongArch Linux kernel (the first draft used -shared) and then the
> patch was revised to use -static -pie --no-dynamic-linker instead (the
> same combination that gcc -static-pie passes to ld).
> 
> Thus IMO having -pie for embedded to support gcc -static-pie makes sense
> in general (some years ago I already wanted this when I had to refactor
> a bare-metal ARM firmware for the ability being loaded by a first-stage
> bootloader).  I'm unsure about -shared but maybe it should be allowed
> too (conceptually I'd consider Linux kernel modules some "non-SVR4"
> shared objects instead of relocatable objects, and the current approach
> treating them as relocatable objects prevents things like linker
> relaxation and LTO).
> 

I totally agree on the static PIE vs shared, I'd be okay, personally,
with only static PIE support. That is what Limine itself does and what
relocatable Limine protocol executables should do.

The reason why I even brought up and added -shared is that the
x86_64-elf and aarch64-elf toolchains do support it, so it would be an
asymmetry to not do so on riscv and loongarch.

> --
> Xi Ruoyao <xry111@xry111.site>
>