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 24440 invoked from network); 9 Sep 2020 21:36:59 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Sep 2020 21:36:59 -0000 Received: (qmail 19837 invoked by uid 550); 9 Sep 2020 21:36:57 -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 19814 invoked from network); 9 Sep 2020 21:36:56 -0000 Date: Wed, 9 Sep 2020 17:36:44 -0400 From: Rich Felker To: Palmer Dabbelt Cc: musl@lists.openwall.com Message-ID: <20200909213644.GB3265@brightrain.aerifal.cx> References: <20200909202824.GZ3265@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] riscv32 v2 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. 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. Rich