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=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23148 invoked from network); 10 Sep 2020 07:37:09 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 Sep 2020 07:37:09 -0000 Received: (qmail 21939 invoked by uid 550); 10 Sep 2020 07:37:07 -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 21916 invoked from network); 10 Sep 2020 07:37:06 -0000 X-Gm-Message-State: AOAM5311K6yqMIMZh/vVsiBmArjba43h5fcr2X6pK+uyBHUtwnDqyBk6 JFHr+xuyUAJqUQH0gEJ65BPwAsvw9VoHu4LxMLU= X-Google-Smtp-Source: ABdhPJxA6SrBLAMdKLlM15hshP8L+FRhP1Zm+tm/TC83Y8RycIDmxR2NlYR7gSOVdIUs1wU6wdjUjB58soRD9JcTysI= X-Received: by 2002:a37:a04b:: with SMTP id j72mr6872095qke.352.1599723413452; Thu, 10 Sep 2020 00:36:53 -0700 (PDT) MIME-Version: 1.0 References: <20200909213644.GB3265@brightrain.aerifal.cx> In-Reply-To: From: Arnd Bergmann Date: Thu, 10 Sep 2020 09:36:36 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Palmer Dabbelt Cc: Rich Felker , musl@lists.openwall.com, Vincenzo Frascino Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:pDh8kuV311jruYlXr3ojlp1nm8qrQ1Go29AfKkENunZ1zdP8IHA 8F8iagSPEu+B9pp26gYSNIs7BUeHdoAAt5INViVESf65EV/Q4S2JGvzaCoOXrbOiLBXlaq6 rt4R30b21/x09eEfbwAvpLsY+JcGLvR5I9qSQ3CenAiBJhhoraXgcR6LLCdnSznCr/qE39q dqgLFFMZYD/icW1Nyc7rA== X-UI-Out-Filterresults: notjunk:1;V03:K0:B/atLPS7DtE=:oDb9Wp9kyLQ57gbH9J/knh ynQOxPDuDTR3NF+e3Z6n7sEwD6Nnmu6fxN1WVukVV5qOs9iSYhcK0mBwN+FlP4gT2Zdozch8o G3eA+qsWrV+BX+o3iMAvHdqtc1Gqi1ieqnT3G4ltzMmF6Zg+4KQ5Q7Uv2FfzpsPudiGKwlchE 2mhrI6lisRjh6fNwQCSEMSE8P5ODmZmhzJFmsrdxo78r7l5TLNmPFdNh9Dd+CzmERDq0Oyd0/ a6PamLHfMrX6F01Aiu4YFDXflt4vWsrimhxf5RJzZkqxNIFaXRb0yUlWDYrDk00ivZCdqMr2u qFLqmy0+/lCvkrmzOp+ddrrfkjJzfvJmJj1LEpFBrejn/suTbhD+3cWBqrp8jxhQ/3il2fHjV YsneSpLhSG/BVNbEMoU4+MOKTXUxKE36/pbxsUufEyL2CpaxmGNe8JKf1WsvEhOidmHM8fXYE iBbQxknzIdQyb0eVJ8pdqnL8f4NM4aoPKR53zgv1jxpGzYAdDCJNAQTfg4IE62Schb1Zi2469 fy+dHqAuYlj3YWh4NSUfg6JxRc5+gJn93sIwWsMzkFqa+FmMMUqGr8chVpJaIgfgEIlRhQoE+ AyQ+GyVGOgQ0/6nQ6dcEm9Gwm0N93O6LbK2in9AwvypjLYwPyo0We28pB8SOqPKQ9LDh1t2Kc sQyu5oS6j1CBMeBgDwL7Ns/MNmCfSq3hCGNlT2401X+lhyMqiNkAyFVLVpD+lb2/xKl0tSbde 06l9AmZIMcjvabMAJG7T4J8GnJYrGPpKSCDn0Ee/0ceEXIyVAW3cLlr5v2TleqAXXuYVf+kQI W35QR6Vcls7v/SX10Y7U/eMsKfLi30wVCg0NrQgMiEzmeC0MMaqyrHuLZySqrMSdTn7phma Subject: Re: [musl] riscv32 v2 On Thu, Sep 10, 2020 at 1:08 AM Palmer Dabbelt wrote: > 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: > > 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 When the vdso for rv64 was added, there was no time64 support in the vdso code in general, as this only came with the "generic vdso" infrastructure that was added later on, with commit ad5d1122b82f ("riscv: use vDSO common flow to reduce the latency of the time-related functions") in v5.8. At that point it probably should have been added as well. > --- 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. For rv32 you need clock_gettime64, not clock_gettime, which in the Linux ABI refers to the interface with the old timespec. There was some debate over whether clock_getres_time64 and gettimeofday_time64 would make sense to be added here, but I have so far leaned to the position that these are not as performance critical and not worth the effort. Vincenzo has argued that we might want to extend the generic vdso code to include a number of additional syscall implementations, which would then include gettimeofday_time64 and clock_getres_time64. Arnd