diff mbox

RISC-V glibc Port v1

Message ID mhng-0841ade8-3952-4e47-8c27-55c8cd09c819@palmer-si-x1c4
State New, archived
Headers

Commit Message

Palmer Dabbelt June 14, 2017, 8:15 p.m. UTC 
  On Wed, 14 Jun 2017 13:02:40 PDT (-0700), fweimer@redhat.com wrote:
> Palmer Dabbelt <palmer@dabbelt.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
clean ABI?

Comments

Florian Weimer June 14, 2017, 8:35 p.m. UTC | #1 
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
Arnd Bergmann June 14, 2017, 9:13 p.m. UTC | #2 
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
Joseph Myers June 14, 2017, 9:25 p.m. UTC | #3 
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.
Palmer Dabbelt June 14, 2017, 9:55 p.m. UTC | #4 
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 mbox

Patch

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