| Message ID | mhng-0841ade8-3952-4e47-8c27-55c8cd09c819@palmer-si-x1c4 |
|---|---|
| State | New |
| Headers | show |
On 06/14/2017 10:15 PM, Palmer Dabbelt wrote: > Do you have an idea of when there will be a 64-bit time_t clean release? I'd > be OK holding off on the 32-bit port for a bit, as we don't expect RV32I-based > Linux-compatible systems to be popular. Sorry, no idea. I'm Cc:ing Arnd, who believe worked on the kernel side of things. > One sticking point is that the RV32I and RV64I base ISAs are very similar, and > as such share a lot of code. I'd prefer to avoid removing the rv32 code just > to add it back in later, as that will be a big headache. > > Would it be sufficient to just disallow RV32I in our preconfigure with a patch > like this, and then turn RV32I back on when we can support a 64-bit time_t > clean ABI? I think that would be acceptable. aarch64 is basically in the same boat today (but they want to use a 32-bit time_t for their ILP32 port). Thanks, Florian
On Wed, Jun 14, 2017 at 10:35 PM, Florian Weimer <fweimer@redhat.com> wrote: > On 06/14/2017 10:15 PM, Palmer Dabbelt wrote: >> Do you have an idea of when there will be a 64-bit time_t clean release? I'd >> be OK holding off on the 32-bit port for a bit, as we don't expect RV32I-based >> Linux-compatible systems to be popular. > > Sorry, no idea. I'm Cc:ing Arnd, who believe worked on the kernel side > of things. Progress has been slow for a while, but there are still a number of interested parties, so it is continuing. I don't think it's important to wait here, as 64-bit time_t will be available for all architectures in glibc once the kernel support is done, the question is more about rebuilding all 32-bit binaries in a distro after the change. Arnd
Note that if you do include the 32-bit port, you may want a bits/environments.h header, as for other architectures with both 32-bit and 64-bit ABIs.
On Wed, 14 Jun 2017 14:13:45 PDT (-0700), Arnd Bergmann wrote: > On Wed, Jun 14, 2017 at 10:35 PM, Florian Weimer <fweimer@redhat.com> wrote: >> On 06/14/2017 10:15 PM, Palmer Dabbelt wrote: >>> Do you have an idea of when there will be a 64-bit time_t clean release? I'd >>> be OK holding off on the 32-bit port for a bit, as we don't expect RV32I-based >>> Linux-compatible systems to be popular. >> >> Sorry, no idea. I'm Cc:ing Arnd, who believe worked on the kernel side >> of things. > > Progress has been slow for a while, but there are still a number of interested > parties, so it is continuing. I don't think it's important to wait > here, as 64-bit > time_t will be available for all architectures in glibc once the kernel support > is done, the question is more about rebuilding all 32-bit binaries in a distro > after the change. OK, then I vote we don't wait for RV32 support. While I don't think there's going to be a flood of RV32 Linux-compatible hardware it'd be easier to port userspace to both RV32 and RV64 at the same time, rather than doing it twice. Does that sound OK?
diff --git a/sysdeps/riscv/preconfigure b/sysdeps/riscv/preconfigure index 43e2a4fac0..a15e563a31 100644 --- a/sysdeps/riscv/preconfigure +++ b/sysdeps/riscv/preconfigure @@ -3,7 +3,11 @@ flen=`$CC $CFLAGS $CPPFLAGS -E -dM -xc /dev/null | sed -n 's/^#define __riscv_fl float_abi=`$CC $CFLAGS $CPPFLAGS -E -dM -xc /dev/null | sed -n 's/^#define __riscv_float_abi_\([^ ]*\) .*/\1/p'` case "$xlen" in -32 | 64) +32) + echo "rv32i is not supported, we're waiting for a 64-bit time_t clean ABI" >&2 + exit 1 + ;; +64) ;; *) echo "Unable to determine XLEN" >&2