<div dir="auto">LGTM :)</div><div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">mintsuki <<a href="mailto:mintsuki@protonmail.com">mintsuki@protonmail.com</a>>於 2026年9月9日週三，09:07寫道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">riscv*-elf is the only RISC-V target for which ld refuses -shared and<br>
-pie. elf32lriscv-defs.sh has withheld GENERATE_SHLIB_SCRIPT and<br>
GENERATE_PIE_SCRIPT from it since be1dce26256a ("RISC-V: Disable shared<br>
library support for embedded elf."), whose commit message is a ChangeLog<br>
entry and records no reason. Nothing in the RISC-V backend depends on<br>
the exclusion, and riscv*-elf does not even set EMBEDDED.<br>
<br>
Other bare-metal ELF targets do generate the scripts. aarch64*-elf was<br>
given PIE support deliberately, in 3af09e8db308 ("Support -pie for<br>
aarch64*-elf targets."), and arm-elf and x86_64-elf have both. The<br>
general question was raised in f2aaebdb9797 ("GENERATE_SHLIB_SCRIPT vs.<br>
EMBEDDED.") and settled the other way: that patch was reverted in<br>
8a46e447a88d, the author concluding that the ELF and program headers are<br>
still written to the file, so an embedded ELF target producing an ET_DYN<br>
image is not the mistake he had taken it for.<br>
<br>
ld/<br>
* emulparams/elf32lriscv-defs.sh (GENERATE_SHLIB_SCRIPT): Set<br>
unconditionally rather than only for non-riscv*-elf targets.<br>
(GENERATE_PIE_SCRIPT): Likewise.<br>
<br>
Assisted-by: Claude:claude-opus-5<br>
Signed-off-by: Mintsuki <<a href="mailto:mintsuki@protonmail.com" target="_blank">mintsuki@protonmail.com</a>><br>
---<br>
ld/emulparams/elf32lriscv-defs.sh | 11 ++---------<br>
1 file changed, 2 insertions(+), 9 deletions(-)<br>
<br>
diff --git a/ld/emulparams/elf32lriscv-defs.sh b/ld/emulparams/elf32lriscv-defs.sh<br>
index 01655616..5c0dac2a 100644<br>
--- a/ld/emulparams/elf32lriscv-defs.sh<br>
+++ b/ld/emulparams/elf32lriscv-defs.sh<br>
@@ -16,15 +16,8 @@ if test `echo "$host" | sed -e s/64//` = `echo "$target" | sed -e s/64//`; then<br>
esac<br>
fi<br>
<br>
-# Enable shared library support for everything except an embedded elf target.<br>
-case "$target" in<br>
- riscv*-elf)<br>
- ;;<br>
- *)<br>
- GENERATE_SHLIB_SCRIPT=yes<br>
- GENERATE_PIE_SCRIPT=yes<br>
- ;;<br>
-esac<br>
+GENERATE_SHLIB_SCRIPT=yes<br>
+GENERATE_PIE_SCRIPT=yes<br>
<br>
IREL_IN_PLT=<br>
TEXT_START_ADDR=0x10000<br>
--<br>
2.55.0<br>
<br>
<br>
On Wednesday, September 9th, 2026 at 9:04 AM, mintsuki <<a href="mailto:mintsuki@protonmail.com" target="_blank">mintsuki@protonmail.com</a>> wrote:<br>
<br>
> ld refuses both -shared and -pie for riscv*-elf and loongarch*-elf,<br>
> because their emulparams files withhold GENERATE_SHLIB_SCRIPT and<br>
> GENERATE_PIE_SCRIPT from those two targets specifically. This is not<br>
> the EMBEDDED policy at work -- neither file sets EMBEDDED -- but a pair<br>
> of one-off "case $target" checks: be1dce26256a for RISC-V, copied into<br>
> the LoongArch port from it. Other bare-metal ELF targets generate the<br>
> scripts; aarch64*-elf was given PIE support on purpose in 3af09e8db308,<br>
> and f2aaebdb9797, which would have taken it away from EMBEDDED targets<br>
> generally, was reverted in 8a46e447a88d:<br>
> <br>
> <a href="https://inbox.sourceware.org/binutils/20191108103411.GU6708@bubble.grove.modra.org/" rel="noreferrer" target="_blank">https://inbox.sourceware.org/binutils/20191108103411.GU6708@bubble.grove.modra.org/</a><br>
> <br>
> What this blocks in practice is freestanding relocatable outputs.<br>
> Those need -pie (or, alternatively, -shared -Bsymbolic), as already<br>
> supported by x86_64-elf, i686-elf, aarch64-elf, etc...<br>
> On riscv64-elf and loongarch64-elf compilers accept -fPIE and -fPIC,<br>
> but the link step using ld.bfd dies with "-pie not supported" or<br>
> "-shared not supported", so a bare-metal toolchain, that is otherwise<br>
> complete, cannot build a freestanding relocatable output. A *-linux<br>
> (or otherwise other hosted) ld.bfd (or LLVM's lld) has to be used<br>
> for the link step instead.<br>
> <br>
> Patch 2 is testsuite preparation. Three LoongArch DT_RELR tests write<br>
> out the symbol index of r_info in full, and that index depends on the<br>
> default hash style: GNU hash requires undefined symbols to precede<br>
> defined ones in .dynsym, so an undefined weak in those tests sorts to<br>
> index 2 under the linux default of "both" and to the end of the table<br>
> under the bare-metal default of sysv. The relocations themselves are<br>
> correct either way. Without that patch, patch 3 turns those three from<br>
> unsupported into FAIL.<br>
> <br>
> Based on 2986ed8ba365 ("Constify targ_desc"). Tested with gcc 16.2.0<br>
> riscv64-elf and loongarch64-elf toolchains and dejagnu 1.6.3.<br>
> make check-ld, before and after the series:<br>
> <br>
> riscv64-elf 541 -> 763 passes, 0 unexpected failures either way<br>
> loongarch64-elf 540 -> 703 passes, 0 unexpected failures either way<br>
> <br>
> No test regresses on either target, and there are no unexpected<br>
> successes; the increase is the shared and PIE tests that were previously<br>
> skipped now running. I have not tested the 32-bit variants, riscv32-elf<br>
> and loongarch32-elf, which the same emulparams files cover.<br>
> <br>
> Mintsuki (3):<br>
> RISC-V: Enable shared library and PIE support for riscv*-elf<br>
> ld: Pin the hash style in the LoongArch DT_RELR shared tests<br>
> LoongArch: Enable shared library and PIE support for loongarch*-elf<br>
> <br>
> ld/emulparams/elf32loongarch-defs.sh | 11 ++---------<br>
> ld/emulparams/elf32lriscv-defs.sh | 11 ++---------<br>
> ld/emulparams/elf64loongarch-defs.sh | 11 ++---------<br>
> ld/testsuite/ld-loongarch-elf/relr-data-shared.d | 2 +-<br>
> ld/testsuite/ld-loongarch-elf/relr-discard-shared.d | 2 +-<br>
> ld/testsuite/ld-loongarch-elf/relr-got-shared.d | 2 +-<br>
> 6 files changed, 9 insertions(+), 30 deletions(-)<br>
> <br>
</blockquote></div></div>