This is the mail archive of the
mailing list for the glibc project.
Re: RISC-V glibc Port v1
- From: Palmer Dabbelt <palmer at dabbelt dot com>
- To: fweimer at redhat dot com
- Cc: libc-alpha at sourceware dot org
- Cc: Andrew Waterman <andrew at sifive dot com>
- Cc: patches at groups dot riscv dot org
- Cc: Darius Rad <darius at bluespec dot com>
- Date: Wed, 14 Jun 2017 13:15:26 -0700 (PDT)
- Subject: Re: RISC-V glibc Port v1
- Authentication-results: sourceware.org; auth=none
On Wed, 14 Jun 2017 13:02:40 PDT (-0700), firstname.lastname@example.org wrote:
> Palmer Dabbelt <email@example.com> writes:
>> This port targets Version 2.2 of the RISC-V User ISA, and supports
>> both the RV32I and RV64I base ISAs as well as the M, A, F, D, and C
>> extensions as well as our Linux port which is based on the 1.10
>> supervisor specification.
> I would recommend to delay the addition of the 32-bit port, so that you
> can start with a 64-bit time_t.
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.
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
diff --git a/sysdeps/riscv/preconfigure b/sysdeps/riscv/preconfigure
index 43e2a4fac0..a15e563a31 100644
@@ -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)
+ echo "rv32i is not supported, we're waiting for a 64-bit time_t clean ABI" >&2
+ exit 1
echo "Unable to determine XLEN" >&2