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

[mintsuki]

I have resent the patchset with the commit messages updated.

Not sure if I did it right, but this is the patchset as per
sourceware.org/pipermail:

https://sourceware.org/pipermail/binutils/2026-September/151332.html
https://sourceware.org/pipermail/binutils/2026-September/151333.html
https://sourceware.org/pipermail/binutils/2026-September/151334.html
https://sourceware.org/pipermail/binutils/2026-September/151335.html

And the patchwork.sourceware.org:

https://patchwork.sourceware.org/project/binutils/list/?series=66225


On Tuesday, September 8th, 2026 at 11:17 PM, mintsuki <mintsuki@protonmail.com> wrote:

> 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>
> >