Re: riscv port for review

[Szabolcs Nagy <nsz@port70.net>]

* 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).

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.