On Wed, Sep 30, 2026 at 03:38:13PM +0200, Nathan Chancellor wrote: > On Tue, Sep 29, 2026 at 11:24:11AM -0700, Nick Desaulniers wrote: > > arch/arm64/kvm/hyp/nvhe/Makefile has this pattern for exactly the same > > problem I suspect. Maybe that's the right tool in the toolbox? > > > > ``` > > diff --git a/arch/riscv/kernel/vdso/Makefile > > b/arch/riscv/kernel/vdso/Makefile > > index 8dbf2532a573..27fa72d8fb86 100644 > > --- a/arch/riscv/kernel/vdso/Makefile > > +++ b/arch/riscv/kernel/vdso/Makefile > > @@ -27,7 +27,7 @@ asflags-y += -DVDSO_CFI=1 > > endif > > > > # Files to link into the vdso > > -obj-vdso = $(patsubst %, %.o, $(vdso-syms)) note.o > > +obj-vdso = $(patsubst %, %.o, $(vdso-syms)) note.o ../../lib/memset.o > > > > ifdef CONFIG_VDSO_GETRANDOM > > obj-vdso += vgetrandom-chacha.o > > ``` > > Fixes `make -skj"$(nproc)" ARCH=riscv LLVM=1 mrproper allmodconfig > > vdso_prepare` for me, as per > > For the record, this also happens with the 32-bit PowerPC vDSO, as I > noted in the commit message of v2. I should update the issue too, I only > realized this after wider testing. So if this is the route we want to > go, we would need a memset() for that vDSO as well. > > > https://github.com/ClangBuiltLinux/linux/issues/2183 > > (Nathan, don't forget to link to that in the commit message) > > Yes, thanks, I have added it for v3. > > > I'm surprised I didn't need -fno-semantic-interposition (or one of the > > related flags... -fvisibility=hidden) > > > > If we want to get better, (if performance matters here and we want to > > trade source+build system complexity for absolute code perf) I would > > start with that, then worry about clawing back performance via things > > like: > > - __builtin_memset_inline > > - -finline-stringops=memset > > - -ffunction-sections+-Wl,--gc-sections to dead code eliminate the out > > of line copy of memset, though IIRC there's potential for wasted space > > due to alignment requirements (maybe the out of line copy of memset is > > smaller...idk) > > Yeah, I guess it is ultimately up to the maintainers what route they > prefer.
I think linking in an out-of-line memset.o is not appealing. This isn't a general library or something. So let's just go with your v2 approach, fixed up in the ways we mentioned.
