On Fri, 12 Jan 2024 13:35:39 PST (-0800), Richard Henderson wrote:
> On 1/12/24 08:49, Vineet Gupta wrote:
>> Hi Richard, Alistair
>> 
>> On 10/30/23 14:17, Richard Henderson wrote:
>>> diff --git a/linux-user/riscv/Makefile.vdso b/linux-user/riscv/Makefile.vdso
>>> new file mode 100644
>>> index 0000000000..2c257dbfda
>>> --- /dev/null
>>> +++ b/linux-user/riscv/Makefile.vdso
>>> @@ -0,0 +1,15 @@
>>> +include $(BUILD_DIR)/tests/tcg/riscv64-linux-user/config-target.mak
>>> +
>>> +SUBDIR = $(SRC_PATH)/linux-user/riscv
>>> +VPATH += $(SUBDIR)
>>> +
>>> +all: $(SUBDIR)/vdso-32.so $(SUBDIR)/vdso-64.so
>>> +
>>> +LDFLAGS = -nostdlib -shared -fpic -Wl,-h,linux-vdso.so.1 
>>> -Wl,--build-id=sha1 \
>>> +     -Wl,--hash-style=both -Wl,-T,$(SUBDIR)/vdso.ld
>>> +
>>> +$(SUBDIR)/vdso-32.so: vdso.S vdso.ld vdso-asmoffset.h
>>> +   $(CC) -o $@ $(LDFLAGS) -mabi=ilp32d -march=rv32g $<
>>> +
>>> +$(SUBDIR)/vdso-64.so: vdso.S vdso.ld vdso-asmoffset.h
>>> +   $(CC) -o $@ $(LDFLAGS) -mabi=lp64d -march=rv64g $<
>> 
>> So by default qemu ships the vdso binary. How can one rebuild it ?
>> 
>>  From skimming the build files it seems following ought to do it
>>      make update-linux-vdso
>> 
>> with a prior configure cmd like below with PATH pointing to the cross
>> compiler.
>> ../configure  --target-list=riscv64-linux-user
>> --cross-cc-riscv64=riscv64-unknown-linux-gnu-gcc
>
> Yes, that should do it.
>
>> But it doesn't, I'm sure we are missing something basis here.
>
> Do you get an error message?
> Did $(BUILD_DIR)/tests/tcg/riscv64-linux-user/config-target.mak get created 
> properly?
>
>> For starters we saw something that seems like a thinko in
>> 
>> diff --git a/linux-user/riscv/vdso.S b/linux-user/riscv/vdso.S
>> -#define sizeof_reg     (__riscv_xlen / 4)
>> +#define sizeof_reg     (__riscv_xlen / 8)
>
> Oops.
>
>> As as aside, we also see that rt_sigreturn in kernel vdso elides the
>> explicit the call frame information. Again we naively don't know if that
>> is required in qemu.
>> 
>>      .text
>> ENTRY(__vdso_rt_sigreturn)
>>      .cfi_startproc
>>      .cfi_signal_frame
>>      li a7, __NR_rt_sigreturn
>>      ecall
>>      .cfi_endproc
>> ENDPROC(__vdso_rt_sigreturn)
>
> Perhaps it's not required, no.  But I'd consider the lack of info from the 
> kernel to be a 
> bug.  Lack of it means places like gcc have to have special cases.

Ya, I agree.  We've tried to avoid too many RISC-V-specific hacks for 
this, but it's bitten me a few times in embedded codebases and it's 
always a headache.

Reviewed-by: Palmer Dabbelt <pal...@rivosinc.com>

Thanks!

Looks like we've got essentially the same thing in Linux already, so I 
think we're safe over there.

>
>
>
> r~
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "gnu-toolchain" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to gnu-toolchain+unsubscr...@rivosinc.com.
> To view this discussion on the web visit 
> https://groups.google.com/a/rivosinc.com/d/msgid/gnu-toolchain/119848b9-0cd7-4d33-bc43-385c86069388%40linaro.org.
> For more options, visit https://groups.google.com/a/rivosinc.com/d/optout.

Reply via email to