From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13329 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: riscv port for review Date: Fri, 28 Sep 2018 10:26:12 -0400 Message-ID: <20180928142612.GT17995@brightrain.aerifal.cx> References: <20180928022404.GQ17995@brightrain.aerifal.cx> <20180928024749.GS17995@brightrain.aerifal.cx> <20180928103354.GK10209@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1538144665 24999 195.159.176.226 (28 Sep 2018 14:24:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2018 14:24:25 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) Cc: palmer@sifive.com To: musl@lists.openwall.com Original-X-From: musl-return-13345-gllmg-musl=m.gmane.org@lists.openwall.com Fri Sep 28 16:24:21 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1g5tgn-0006K9-LQ for gllmg-musl@m.gmane.org; Fri, 28 Sep 2018 16:24:17 +0200 Original-Received: (qmail 3360 invoked by uid 550); 28 Sep 2018 14:26:26 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3342 invoked from network); 28 Sep 2018 14:26:26 -0000 Content-Disposition: inline In-Reply-To: <20180928103354.GK10209@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13329 Archived-At: On Fri, Sep 28, 2018 at 12:33:54PM +0200, Szabolcs Nagy wrote: > * Michael Clark [2018-09-28 18:33:18 +1200]: > > > On 28/09/2018, at 2:47 PM, Rich Felker 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