From: Rich Felker <dalias@libc.org>
To: Palmer Dabbelt <palmerdabbelt@google.com>
Cc: musl@lists.openwall.com
Subject: Re: [musl] riscv32 v2
Date: Wed, 9 Sep 2020 17:36:44 -0400 [thread overview]
Message-ID: <20200909213644.GB3265@brightrain.aerifal.cx> (raw)
In-Reply-To: <mhng-c1942a99-70fd-472a-8123-c7a2d270b7bd@palmerdabbelt-glaptop1>
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
next prev parent reply other threads:[~2020-09-09 21:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 5:48 Stefan O'Rear
2020-09-07 10:47 ` Stefan O'Rear
2020-09-07 18:06 ` Rich Felker
2020-09-07 21:35 ` Arnd Bergmann
2020-09-07 21:45 ` Rich Felker
2020-09-07 21:58 ` Arnd Bergmann
2020-09-07 22:11 ` Rich Felker
2020-09-07 22:30 ` Arnd Bergmann
2020-09-08 1:02 ` Rich Felker
2020-09-08 7:00 ` Arnd Bergmann
2020-09-07 11:27 ` Stefan O'Rear
2020-09-07 18:09 ` Rich Felker
2020-09-08 1:54 ` Rich Felker
2020-09-09 6:07 ` Rich Felker
2020-09-09 20:28 ` Rich Felker
2020-09-09 21:28 ` Palmer Dabbelt
2020-09-09 21:36 ` Rich Felker [this message]
2020-09-09 23:08 ` Palmer Dabbelt
2020-09-10 7:36 ` Arnd Bergmann
2020-09-10 10:01 ` Vincenzo Frascino
2020-09-11 0:08 ` Palmer Dabbelt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200909213644.GB3265@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
--cc=palmerdabbelt@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).