RISC-V vDSO build error after LLVM commit 90cebef1411617fc3eedd359bdf00cb44b1c2439

[nathanchance]

After llvm/llvm-project@90cebef, I see:

$ make -skj"$(nproc)" ARCH=riscv LLVM=1 mrproper allmodconfig vdso_prepare
arch/riscv/kernel/vdso/vdso.so.dbg: dynamic relocations are not supported
make[4]: *** [arch/riscv/kernel/vdso/Makefile:78: arch/riscv/kernel/vdso/vdso.so.dbg] Error 1
...

[nickdesaulniers]

Are we getting a library call as a result of that change, perhaps?

[nathanchance]

Yeah, looks like we are getting a memset now:

$ llvm-readelf -rW arch/riscv/kernel/vdso/vdso.so.dbg

Relocation section '.rela.plt' at offset 0x3f0 contains 1 entries:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
0000000000000508  0000000100000005 R_RISCV_JUMP_SLOT      0000000000000000 memset + 0

It appears to come from the loop running params->reserved[i] = 0 for the size of reserved in __cvdso_getrandom_data(), as I can make the error disappear altogether with:

diff --git a/lib/vdso/getrandom.c b/lib/vdso/getrandom.c
index 2851afa9154f..7f03e34a6210 100644
--- a/lib/vdso/getrandom.c
+++ b/lib/vdso/getrandom.c
@@ -83,8 +83,10 @@ __cvdso_getrandom_data(const struct vdso_rng_data *rng_info, void *buffer, size_
                params->size_of_opaque_state = sizeof(*state);
                params->mmap_prot = PROT_READ | PROT_WRITE;
                params->mmap_flags = MAP_DROPPABLE | MAP_ANONYMOUS;
-               for (size_t i = 0; i < ARRAY_SIZE(params->reserved); ++i)
+               for (size_t i = 0; i < ARRAY_SIZE(params->reserved); ++i) {
+                       OPTIMIZER_HIDE_VAR(i);
                        params->reserved[i] = 0;
+               }
                return 0;
        }

Prior to that change, -fno-builtin that the RISC-V vDSO builds with would have prevented this transformation because memset() would not be available as a libcall if I remember correctly.

The GCC documentation mentions that memset() is required even in a freestanding environment, so it is possible that a basic one should be provided. This has come up before in commit b7bad082e113 ("random: vDSO: avoid call to out of line memset()"), so maybe the above diff would be acceptable?

[nickdesaulniers]

The GCC documentation mentions that memset() is required even in a freestanding environment

yeah, the compiler is free to assume that memcpy, memmove, memset, and memcmp are always available (even in a free standing environment). Even the barest of metal systems are playing with fire if they don't provide them. Patch LGTM; but probably could use an in line comment about avoiding the compiler producing libcalls to memset.

[nathanchance]

Patch submitted: https://lore.kernel.org/20260916-vdso-getrandom-avoid-memset-llvm-24-v1-1-80a92f2e225a@kernel.org/

[nickdesaulniers]

It looks like this isn't the first time this code path has resulted in a libcall to memcpy being emitted; so we're still playing whack a mole with the vdso for getrandom:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b7bad082e113640fc81200ff869e5c2d7a9c29a2

Clang-15+ (38637ee47754) has __builtin_inline_memset which can be used here:

+     #if __has_builtin(__builtin_memset_inline)
+             __builtin_memset_inline(params->reserved, 0, sizeof(params->reserved));
+     #else
             for (size_t i = 0; i < ARRAY_SIZE(params->reserved); ++i)
                 params->reserved[i] = 0;
+     #endif

to avoid the libcall unconditionally.

GCC can still emit libcalls to memset, even with -fno-builtin, -ffreestanding: https://godbolt.org/z/6hTrYq9z8