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

[mintsuki]

------- Forwarded Message -------
From: mintsuki <mintsuki@protonmail.com>
Date: On Friday, September 4th, 2026 at 7:33 PM
Subject: Re: [PATCH 0/3] ld: shared library and PIE support for riscv*-elf and loongarch*-elf
To: Jan Beulich <jbeulich@suse.com>


> 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.
> 
> 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.
> 
> On Friday, September 4th, 2026 at 7:52 AM, Jan Beulich <jbeulich@suse.com> wrote:
> 
> > On 03.09.2026 19:46, mintsuki wrote:
> > > ld refuses both -shared and -pie for riscv*-elf and loongarch*-elf,
> > > because their emulparams files withhold GENERATE_SHLIB_SCRIPT and
> > > GENERATE_PIE_SCRIPT from those two targets specifically.  This is not
> > > the EMBEDDED policy at work -- neither file sets EMBEDDED -- but a pair
> > > of one-off "case $target" checks: be1dce26256a for RISC-V, copied into
> > > the LoongArch port from it.  Other bare-metal ELF targets generate the
> > > scripts; aarch64*-elf was given PIE support on purpose in 3af09e8db308,
> > > and f2aaebdb9797, which would have taken it away from EMBEDDED targets
> > > generally, was reverted in 8a46e447a88d:
> > >
> > >   https://inbox.sourceware.org/binutils/20191108103411.GU6708@bubble.grove.modra.org/
> > >
> > > What this blocks in practice is UEFI.  A UEFI application is an ET_DYN
> > > image with a PE header stapled on, self-relocating through its
> > > R_*_RELATIVE relocations,
> >
> > Afaik a "normal" UEFI application is an ordinary PE executable. What you
> > describe looks to be the result of some handcrafting. Imo properly
> > supporting the true linking of PE binaries from ELF inputs on the targets
> > of interest (like is already possible on x86-64, for example) would be
> > the better course of action (if UEFI applications are the sole concern
> > here).
> >
> > Jan
> >
> > > so building one needs -pie (or -shared
> > > -Bsymbolic).  On riscv64-elf and loongarch64-elf the compiler accepts
> > > -fPIE and the link then dies with "-pie not supported", so a bare-metal
> > > toolchain that is otherwise complete cannot build one, and a *-linux ld
> > > or lld has to be substituted for the link.
> > >
> > > Patch 2 is testsuite preparation.  Three LoongArch DT_RELR tests write
> > > out the symbol index of r_info in full, and that index depends on the
> > > default hash style: GNU hash requires undefined symbols to precede
> > > defined ones in .dynsym, so an undefined weak in those tests sorts to
> > > index 2 under the linux default of "both" and to the end of the table
> > > under the bare-metal default of sysv.  The relocations themselves are
> > > correct either way.  Without that patch, patch 3 turns those three from
> > > unsupported into FAIL.
> > >
> > > Based on 2986ed8ba365 ("Constify targ_desc").  Tested with gcc 16.2.0
> > > riscv64-elf and loongarch64-elf toolchains and dejagnu 1.6.3.
> > > make check-ld, before and after the series:
> > >
> > >   riscv64-elf       541 -> 763 passes, 0 unexpected failures either way
> > >   loongarch64-elf   540 -> 703 passes, 0 unexpected failures either way
> > >
> > > No test regresses on either target, and there are no unexpected
> > > successes; the increase is the shared and PIE tests that were previously
> > > skipped now running.  I have not tested the 32-bit variants, riscv32-elf
> > > and loongarch32-elf, which the same emulparams files cover.
> > >
> > > Also built the Limine bootloader's UEFI ports for riscv64 and
> > > loongarch64 with those bare-metal toolchains against an ld from this
> > > branch.  Both link, and both boot to Limine's menu under EDK2 in qemu.
> > > The images carry only R_RISCV_RELATIVE / R_LARCH_RELATIVE dynamic
> > > relocations, as they do when the same objects are linked by a *-linux
> > > ld.
> > >
> > > The patches carry an "Assisted-by:" trailer, which is a convention of
> > > the project I hit this in rather than one of yours; it records that an
> > > AI coding assistant helped write the change.  Say the word and I will
> > > resend without it.
> > >
> > > Mintsuki (3):
> > >   RISC-V: Enable shared library and PIE support for riscv*-elf
> > >   ld: Pin the hash style in the LoongArch DT_RELR shared tests
> > >   LoongArch: Enable shared library and PIE support for loongarch*-elf
> > >
> > >  ld/emulparams/elf32loongarch-defs.sh                | 11 ++---------
> > >  ld/emulparams/elf32lriscv-defs.sh                   | 11 ++---------
> > >  ld/emulparams/elf64loongarch-defs.sh                | 11 ++---------
> > >  ld/testsuite/ld-loongarch-elf/relr-data-shared.d    |  2 +-
> > >  ld/testsuite/ld-loongarch-elf/relr-discard-shared.d |  2 +-
> > >  ld/testsuite/ld-loongarch-elf/relr-got-shared.d     |  2 +-
> > >  6 files changed, 9 insertions(+), 30 deletions(-)
> > >
> > >
> >
> >