Implement RISC-V dynamic linking

[DrXiao]

The proposed changes primarily improve the ELF generation and the RISC-V backend, enabling the build system to generate a dynamically linked shecc targeting the RISC-V architecture.

Although the current changes allow both bootstrapping and test suite to complete successfully, this is still a work in progress. The TODO items are listed as follows:

• Enhance code quality, comments and commit messages.
• Confirm the RISC-V ABI compliance.
• Add a new script (riscv-abi.sh) to validate the RISC-V ABI.
• Improve the documentation and README.
• Consolidate arm.mk and riscv.mk into a common build logic (e.g.: configure RUNNER_LD_PREFIX).
• (Any new requirements ...)

---

Summary by cubic

Implements RV32 dynamic linking (RELA + ABI‑compliant PLT/GOT) with a __libc_start_main entry path, and introduces ELF_MACHINE_* macros to select REL (ARM) vs RELA (RISC‑V). CI now builds/tests static and dynamic for both arm and riscv, and an ABI test suite validates RV32 calling/stack rules.

• New Features

  • RV32 dynamic linking: .rela.plt; PLT0=32B, stubs=16B; per‑arch RESERVED_GOT_NUM (RV32=2, ARM=3); DYN_LINKER /lib/ld-linux-riscv32-ilp32d.so.1.
  • ELF: ELF_MACHINE_ARM32/ELF_MACHINE_RV32; REL (ARM) vs RELA (RV32); correct dynamic tags (RELA/RELASZ/RELAENT/JMPREL/PLTREL/PLTRELSZ); .got init honors reserved entries.
  • RISC‑V backend: ABI‑compliant PLT generator; internal calls direct, externs via PLT; entry calls __libc_start_main then returns via saved ra; syscall trampoline kept for static; stack stays 16‑byte aligned.
  • Tests/CI: RISC‑V ABI suite (tests/riscv-abi.sh); RV32 dynamic snapshots (hello, fib); ABI checks for arm and riscv; CI matrix runs static+dynamic on both.

• Dependencies

  • Shared toolchain detection in mk/common.mk with per‑arch TOOLCHAIN_CANDIDATES; GitHub Actions installs a riscv32 glibc toolchain and adds /opt/riscv/bin to PATH; RUNNER_LD_PREFIX auto‑set under QEMU.

^{Written for commit 1af9140. Summary will update on new commits.}

[DrXiao]

As the apt package manager only provides a 64-bit RISC-V GNU cross-compilation toolchain, I utilize riscv-gnu-toolchain , which is a 32-bit variant, and leverage its artifacts for RISC-V dynamic linking development and validation.

The updated GitHub Actions also downloads the 32-bit variant to validate RISC-V dynamic linking.

[jserv]

As the apt package manager only provides a 64-bit RISC-V GNU cross-compilation toolchain, I utilize riscv-gnu-toolchain , which is a 32-bit variant, and leverage its artifacts for RISC-V dynamic linking development and validation.
The updated GitHub Actions also downloads the 32-bit variant to validate RISC-V dynamic linking.

Evaluate Run 32-bit applications on 64-bit Linux kernel, which is exactly RV32-on-RV64 userspace compatibility, not emulation.

[DrXiao]

Evaluate Run 32-bit applications on 64-bit Linux kernel, which is exactly RV32-on-RV64 userspace compatibility, not emulation.

I'm not sure whether I understand correctly. Do you mean that the proposed changes should be verified on a RISC-V machine?

[jserv]

Do you mean that the proposed changes should be verified on a RISC-V machine?

See sysprog21/kbox#18
The RISE RISC-V Runners is a managed GitHub Actions runner service that executes CI/CD workflows on real RISC-V hardware.

[DrXiao]

RISE RISC-V Runners' documentation explicitly states that binaries must be compiled for riscv64. According to the FAQ - What architectures are supported?.

RISC-V 64-bit (riscv64) only. All runners execute on physical RISC-V hardware. There is no RISC-V emulation. Binaries must be compiled for riscv64.

I created another branch (feat/dynlink-for-rv32-test-rv64-runner) to verify if these RISC-V runners could support riscv32 binaries. However, the test result indicates that the runner failed to execute statically linked shecc.

Based on both the documentation and my test, it appears that RISE RISC-V runners lack support for 32-bit executables.

[DrXiao]

RISC-V calling convention:

1. First eight arguments are passed to a0-a7, and the extra arguments are pushed onto the stack.
2. stack should be 128-bit (16-byte) aligned. In RISC-V ABIs Specification document, the section 2-1 describes

   2-1. Integer Calling Convention

   The stack grows downwards (towards lower addresses) and the stack pointer shall be aligned to a
   128-bit boundary upon procedure entry.

3. Caller/Callee saved registers:

   Register ABI Name	Saver
   zero, gp, tp	(None)
   ra	Caller
   sp	Callee
   a0 - a7	Caller
   s0 - s11	Callee
   t0 - t6	Caller

---

Item 1: is done by the register allocation phase.

The register allocator uses virtual registers (vreg0-vreg7) to allocate reigsters for arguments when encountering a function call. vreg0-vreg7 will be mapped to a0-a7, so first eight arguments are naturally passed to these registers.

Since the current shecc only supports up to 8 arguments, no extra arguments need to be passed to the stack. Thus, we can skip this handling.

Item 2: is ensured by the RISC-V code generator.

When handling the stack pointer, the code generator will guarantee that sp is always incremented or decremented by a multiple of 16 bytes.

Item 3:

• ra and sp: are properly handled by the code generator.
• a0 - a7: are implicitly handled in register allocation phase.
• s0 - s11: are not necessary to be preserved or restored.
• t0 - t6: are not necessary to be handled.

Therefore, this item can also be considered complete. Further details and explanations can be found in riscv-codegen.c.