Re: glibc for 32-bit kernel without __ARCH_WANT_TIME32_SYSCALLS

[Alistair Francis <alistair23 at gmail dot com>]

On Sun, Jun 23, 2019 at 7:40 AM Palmer Dabbelt <palmer@sifive.com> wrote:
>
> On Fri, 21 Jun 2019 02:34:18 PDT (-0700), fweimer@redhat.com wrote:
> > * Alistair Francis:
> >
> >> Linux 5.1 has removed the __ARCH_WANT_TIME32_SYSCALLS define for the
> >> RISC-V 32-bit port. This means that glibc (with the latest 32-bit
> >> RISC-V port submission) fails to build as there are a lot of missing
> >> syscalls, __NR_futex is the first one I see.
> >>
> >> I looked at adjusting the syscalls to use the new 64-bit versions
> >> (such as __NR_futex64) but this seems to be a large job with a lot of
> >> manual changes. Is there a better way that I should be doing this?
> >> Have any other 32-bit architectures removed
> >> __ARCH_WANT_TIME32_SYSCALLS or are in the process of removing
> >> __ARCH_WANT_TIME32_SYSCALLS?
> >
> > Maybe look at the x86-64 x32 port?  It may make sense to align with that
> > and pretend that the time-related system calls are always 64-bit on the
> > 32-bit RISC-V port.
>
> The plan is to just actually always have 64-bit kernel time calls on 32-bit
> RISC-V, which is what has been blocking the port.  I was under the impression
> it was possible to do this with a very new kernel, but I haven't had time to
> actively look in to it so I might be wrong.

It is possible with a new kernel, but I don't see a straight forward
way to do this in glibc. No other architecture seems to do this today.

I sent a RFC series with an attempt to do it [1], feedback is very
welcome. I can't tell if I'm on the right track or just way off.

1: https://sourceware.org/ml/libc-alpha/2019-06/msg00534.html

Alistair

>
> I'm adding Arnd, who was doing the work on the kernel side.
>
> Arnd: I'm not sure if you read libc-alpha.  Can we pull the tirgger in a
> 64-bit-only time_t rv32i glibc port?