Re: riscv port for review

[Rich Felker <dalias@libc.org>]

On Fri, Sep 28, 2018 at 12:33:54PM +0200, Szabolcs Nagy wrote:
> * Michael Clark <michaeljclark@mac.com> [2018-09-28 18:33:18 +1200]:
> > > On 28/09/2018, at 2:47 PM, Rich Felker <dalias@libc.org> wrote:
> > > 
> > >> On Thu, Sep 27, 2018 at 10:24:04PM -0400, Rich Felker wrote:
> > >> Pulled from here:
> > >> https://github.com/riscv/riscv-musl/commit/6a4f4a9c774608add4b02f95322518bd2f5f51ee
> > >> 
> > >> Attached for review.
> > > 
> > >> diff --git a/arch/riscv32/bits/alltypes.h.in b/arch/riscv32/bits/alltypes.h.in
> > >> new file mode 100644
> > >> index 0000000..66ca18a
> > >> --- /dev/null
> > >> +++ b/arch/riscv32/bits/alltypes.h.in
> > >> @@ -0,0 +1,26 @@
> > >> +#define _Addr int
> > >> +#define _Int64 long long
> > >> +#define _Reg int
> > >> +
> > >> +TYPEDEF __builtin_va_list va_list;
> > >> +TYPEDEF __builtin_va_list __isoc_va_list;
> > >> +
> > >> +#ifndef __cplusplus
> > >> +TYPEDEF int wchar_t;
> > >> +#endif
> > >> +
> > >> +TYPEDEF float float_t;
> > >> +TYPEDEF double double_t;
> > >> +
> > >> +TYPEDEF struct { long long __ll; long double __ld; } max_align_t;
> > >> +
> > >> +TYPEDEF long time_t;
> > > 
> > > Is riscv32 time_t really 32-bit? If so that's really disappointing,
> > > but presumably unfixable...
> > 
> > This definitely is fixable as the riscv32 Linux ABI is not final.
> 
> i think linux is the problem: when x32 tried to do 64bit time_t
> on an ilp32 target it turned out to be a disaster, because
> various driver and fs code can only deal with 32bit time_t when
> long is 32bit (although x32 had other issues too: mixing 64bit
> kernel space and 32bit userspace types).

Are you talking about ioctl interfaces? These need to be fixed at some
point anyway (both for glibc TIME64 profile and musl2) and we can shim
them in userspace with a big list of them. I'd rather do it now than
introduce a new arch/ABI that's broken by design and destined to be
unusable in a few years.

> the consensus after x32 was that new 32bit targets will keep
> using 32bit time_t and there is an independent project to add
> 64bit time_t support (by introducing new syscalls, types etc)
> that will apply to all 32bit targets once it's done.

This is really unfortunate. I'd love it if the rv32 people could
provide some pushback against it.

Rich