GNU ld for RISCV bare metal targets without -shared/-pie support

[Krotti83]

Hi!

Does somebody know, why the GNU ld developers disabled shared library and PIE support on RISCV bare metal targets (riscv64-none-elf)? I'm wondering why PIE is enabled on ARM bare metal targets, but not on RISCV.

I have enabled it in the sources from GNU ld, but currently not tested. The reason was I had big troubles with building Newlib with GCC with the riscv64-linux-gnu configuration. Doesn't worked, because the compilation from libgcc always failed (missing sys/ucontext.h header in libgcc/unwind-dw2.c). Tried also different configuration switches link --disable-libunwind and --disable-libunwind-exceptions, but no success. So I modified GNU ld...

[Octocontrabass]

Why are those enabled for ARM? Bare metal targets can't support shared libraries or position-independent executables, those things depend on the C standard library and the C standard library depends on the OS.

Why are you trying to build Newlib? It'll be easier to figure out the "correct" way to do things if we know what you're trying to do.

[toasterdev]

-elf toolchains don't need a modified ld for PIE anymore. binutils had a patch in 2024 to remove the RISC-V -elf restriction on -shared and -pie.
the sys/ucontext.h error is from using riscv64-linux-gnu. that's the Linux target, whereas riscv64-unknown-elf is intended for bare-metal/Newlib setups.

also, PIE itself doesn't need a C library. ld normally expects a dynamic linker to handle the runtime relocations, but a custom loader can handle those relocations itself.

[nullplan]

also, PIE itself doesn't need a C library. ld normally expects a dynamic linker to handle the runtime relocations, but a custom loader can handle those relocations itself.

And static PIE has the dynamic linker integrated into the executable. Because for static PIE, you really only need to support relative relocations, so that's a single pass over the relocation table and you're done.