mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Palmer Dabbelt <palmerdabbelt@google.com>
To: dalias@libc.org, Arnd Bergmann <arnd@arndb.de>
Cc: musl@lists.openwall.com
Subject: Re: [musl] riscv32 v2
Date: Wed, 09 Sep 2020 16:08:22 -0700 (PDT)	[thread overview]
Message-ID: <mhng-efef4c03-1c58-4b86-9730-87959d73ee9e@palmerdabbelt-glaptop1> (raw)
In-Reply-To: <20200909213644.GB3265@brightrain.aerifal.cx>

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

  reply	other threads:[~2020-09-09 23:10 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
2020-09-09 23:08       ` Palmer Dabbelt [this message]
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=mhng-efef4c03-1c58-4b86-9730-87959d73ee9e@palmerdabbelt-glaptop1 \
    --to=palmerdabbelt@google.com \
    --cc=arnd@arndb.de \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.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).