As mentioned in https://bugs.kde.org/show_bug.cgi?id=468575#c85 An implementation of the riscv_hwprobe syscall (258) is missing, which is used by glibc to implement IFUNC.
The RISC-V Hardware Probing Interface is non-trivial https://docs.kernel.org/arch/riscv/hwprobe.html But at the moment we only have the basic RV64GC instruction set. Which I believe is what glibc assumes if riscv_hwprobe isn't implemented. So as a quick workaround we could just "implement" riscv_hwprobe as ENOSYS. diff --git a/coregrind/m_syswrap/syswrap-riscv64-linux.c b/coregrind/m_syswrap/syswrap-riscv64-linux.c index e0146f2b0dad..ebf9c3105339 100644 --- a/coregrind/m_syswrap/syswrap-riscv64-linux.c +++ b/coregrind/m_syswrap/syswrap-riscv64-linux.c @@ -545,6 +545,7 @@ static SyscallTableEntry syscall_main_table[] = { LINXY(__NR_perf_event_open, sys_perf_event_open), /* 241 */ LINXY(__NR_accept4, sys_accept4), /* 242 */ LINXY(__NR_recvmmsg, sys_recvmmsg), /* 243 */ + GENX_(__NR_riscv_hwprobe, sys_ni_syscall), /* 258 */ PLAX_(__NR_riscv_flush_icache, sys_riscv_flush_icache), /* 259 */ GENXY(__NR_wait4, sys_wait4), /* 260 */ LINXY(__NR_prlimit64, sys_prlimit64), /* 261 */ diff --git a/include/vki/vki-scnums-riscv64-linux.h b/include/vki/vki-scnums-riscv64-linux.h index e4cc04a608b4..17b6839f8a84 100644 --- a/include/vki/vki-scnums-riscv64-linux.h +++ b/include/vki/vki-scnums-riscv64-linux.h @@ -321,6 +321,7 @@ #define __NR_mmap __NR3264_mmap #define __NR_fadvise64 __NR3264_fadvise64 +#define __NR_riscv_hwprobe (__NR_arch_specific_syscall + 14) #define __NR_riscv_flush_icache (__NR_arch_specific_syscall + 15) #endif /* __VKI_SCNUMS_RISCV64_LINUX_H */
commit 5efdbbd321e6816ab2ae436d38c20bdcc72b4c17 Author: Mark Wielaard <mark@klomp.org> Date: Fri May 9 13:46:44 2025 +0200 Add workaround for missing riscv_hwprobe syscall (258) On riscv newer glibc (2.41) will probe instruction support using the riscv_hwprobe syscall. Since Valgrind currently doesn't have a wrapper for riscv_hwprobe that causes a Warning. Since the RISC-V Hardware Probing Interface is non-trivial and we don't really implement extended riscv instructions anyway work around that by "implementing" riscv_hwprobe as sys_ni_syscall so it generates an ENOSYS and glibc will silently fall back to not using any extended instructions. https://docs.kernel.org/arch/riscv/hwprobe.html https://bugs.kde.org/show_bug.cgi?id=503253
Just a comment to note that the current "solution" of just pretending that the riscv_hwprobe syscall doesn't exist (return ENOSYS) isn't ideal and prevents use of extended instruction sets.