Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 9 Sep 2020 17:36:44 -0400
From: Rich Felker <>
To: Palmer Dabbelt <>
Subject: Re: 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), 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.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.