From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-11.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1848 invoked from network); 9 Sep 2020 23:10:29 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Sep 2020 23:10:29 -0000 Received: (qmail 15629 invoked by uid 550); 9 Sep 2020 23:10:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 14066 invoked from network); 9 Sep 2020 23:08:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=jvuDYBI2azyDTgxECq30IYbXSZCHYBLaOooMw40BTyk=; b=m1maFutwLYGNQUwsSbi4wrjL3ptEVwTTxNgyXZ1mcX6GKWIJx2v2IAw9MCfOE1kmhS W15gjUaxyUBowbmsp42tYK09dokcZ1NI022WVoBSqfZDFaljqRGSeKoio11HC1alCaBY Df5TYMas+ZRLGxTDuwZsAco443csdOhwYBreq7xYvyEvpnx1PScIuxOF8WFG6vPZP8fq gcJf1OZIN6Cjx55R0uG686Xqm+5OCvcc+clj9ts9BymA1xs+zJbc/rX+RGnoWOc0WDvG 2AglRjx7jDXNn744pZNhb/Kl5l79jOemIN5ZtgHIxOIqwRoZd1upfOvxNYoeY/o8lTcH O1lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=jvuDYBI2azyDTgxECq30IYbXSZCHYBLaOooMw40BTyk=; b=J9S+Oec/xSCHYipLgF/qLF3VjuGZ3G9y6kJHiN4ocH9HQJHsDTXf5wXadEEeDppsUY DimZ2kJdA5uWyWYhvhD8wYdUfPLln2tq47a4M/fBwSiJjC+5/9oELPCacFtRy9Q4kg8p gx0OXY7uE3weqi0YkOHbiIb/P9R+Fn3b6V68ZDAl70hP65C49TyrZZRTYtQbFXvV/+4C XU+Nts/SBYdP/632rxkQDbwFgGnOd/92PcPs7ZYYzKS1+IR10zmEus+PUNicg3DpB+Uf 5e7mXdaBgM77khgnTKdaaQqyqkpXw0T0BCmjDf1yMkq2fmdEZYQhD3W4Tc3/VsKroGIq UHyQ== X-Gm-Message-State: AOAM532ULXmo1GgyP/MrI9ieYsQZmC7IN+FvrMCzKxg9FUOk4Y3XxF7R CTWdvSThaj1UH96FeoEbnh32+KhJH3pwYCP3 X-Google-Smtp-Source: ABdhPJwD33mABr5VT6fDDg1S8IdwvC1Um+v+K4WATO6fMNIYP5Nzha05W9tLeJOGNgrAUHAM9t2TZA== X-Received: by 2002:a17:90b:1216:: with SMTP id gl22mr2602488pjb.121.1599692902748; Wed, 09 Sep 2020 16:08:22 -0700 (PDT) Date: Wed, 09 Sep 2020 16:08:22 -0700 (PDT) X-Google-Original-Date: Wed, 09 Sep 2020 16:08:19 PDT (-0700) In-Reply-To: <20200909213644.GB3265@brightrain.aerifal.cx> CC: musl@lists.openwall.com From: Palmer Dabbelt To: dalias@libc.org, Arnd Bergmann Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] riscv32 v2 On Wed, 09 Sep 2020 14:36:44 PDT (-0700), dalias@libc.org wrote: > On Wed, Sep 09, 2020 at 02:28:55PM -0700, Palmer Dabbelt wrote: >> On Wed, 09 Sep 2020 13:28:27 PDT (-0700), dalias@libc.org wrote: >> >On Fri, Sep 04, 2020 at 01:48:19AM -0400, Stefan O'Rear wrote: >> >>+#define VDSO_USEFUL >> >>+/* We don't have a clock_gettime function. >> >>+#define VDSO_CGT_SYM "__vdso_clock_gettime" >> >>+#define VDSO_CGT_VER "LINUX_2.6" */ >> >>-- >> >>2.25.4 >> >> >> > >> >Is this correct? I see the comment is just copied from riscv64, but it >> >seems wrong there, and here too. Also, is the vdso function named >> >"clock_gettime" or "clock_gettime64" for riscv32? Or is there none at >> >all and this macro just wrong? >> >> Looks like we don't have __vdso_clock_gettime on rv32 but we do have one on >> rv64. glibc doesn't have the clock VDSO calls on rv32. >> >> I'm not opposed to adding some sort of clock-related VDSO calls on rv32, but it >> looks like doing so will require some thought. Maybe it's best to wait on that >> so we don't hold up the initial port? > > Possible addition of vdso clock_gettime isn't a blocker for moving > forward with the musl port, but syscall_arch.h should accurately > describe what's available and should not attempt to use vdso before > it's a public kernel interface (e.g. resolving the question of what > the function name will be). So I think it should be removed for now. Sorry if that was confusing, but I definitely agree. I guess my point was that the lack of VDSO clock functions on rv32 was probably an oversight, but one that shouldn't block the port. We definitely can't just make up a kernel interface, particularly as the reason we don't have these on rv32 is because the generic versions of the functions we're using don't appear to run on 32-bit targets. That probably means there's some more subtle issue, though TBH I don't know enough about the 64-bit-ification of time_t for it to just jump out at me. I don't want to derail the thread too much, but I tried the obvious thing diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 33dde87218dd..1cf24a8f76c4 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -65,7 +65,7 @@ config RISCV select HAVE_EBPF_JIT if MMU select HAVE_FUTEX_CMPXCHG if FUTEX select HAVE_GCC_PLUGINS - select HAVE_GENERIC_VDSO if MMU && 64BIT + select HAVE_GENERIC_VDSO if MMU select HAVE_PCI select HAVE_PERF_EVENTS select HAVE_PERF_REGS diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile index 478e7338ddc1..10f7a07ce85a 100644 --- a/arch/riscv/kernel/vdso/Makefile +++ b/arch/riscv/kernel/vdso/Makefile @@ -7,9 +7,7 @@ ARCH_REL_TYPE_ABS := R_RISCV_32|R_RISCV_64|R_RISCV_JUMP_SLOT include $(srctree)/lib/vdso/Makefile # Symbols present in the vdso vdso-syms = rt_sigreturn -ifdef CONFIG_64BIT vdso-syms += vgettimeofday -endif vdso-syms += getcpu vdso-syms += flush_icache and it doesn't build. I've added Arnd, who might have a better idea of what's going on. Whatever happens, I think the best bet is to just drop the clock functions (specifically __vdso_{clock_gettime,gettimeofday,clock_getres}) from the rv32 port right now. > But VDSO_USEFUL must be kept if we want to support the vdso icache > flush function (is that actually supported on rv32 either? if not it > should be made conditional on rv64 in src/linux/cache.c. Yes, we have __vdso_flush_icache on rv32 and as far as I know it should work fine (I guess QEMU isn't really going to find fence.i issues, but this interface in particular is quite simple). There's no way to build a working system without some kernel-based fence.i mechanism, and IIRC we added the VDSO entry at the same time as the syscall so it should always work itself out (though we do have the syscall-based fallback in glibc)). One of my working directories reports $ riscv64-linux-gnu-objdump -d arch/riscv/kernel/vdso/vdso.so arch/riscv/kernel/vdso/vdso.so: file format elf32-littleriscv Disassembly of section .text: 00000800 <__vdso_rt_sigreturn@@LINUX_4.15>: 800: 08b00893 li a7,139 804: 00000073 ecall 808: 0000 unimp ... 0000080c <__vdso_getcpu@@LINUX_4.15>: 80c: 0a800893 li a7,168 810: 00000073 ecall 814: 8082 ret ... 00000818 <__vdso_flush_icache@@LINUX_4.15>: 818: 10300893 li a7,259 81c: 00000073 ecall 820: 8082 ret when built for rv32 (despite the rv64 objdump command). > > Rich