From owner-freebsd-arch@freebsd.org Fri Jun 24 10:55:12 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 118EEB73429 for ; Fri, 24 Jun 2016 10:55:12 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id A5BA326C5 for ; Fri, 24 Jun 2016 10:55:11 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-106-149-109.carlnfd1.nsw.optusnet.com.au (c122-106-149-109.carlnfd1.nsw.optusnet.com.au [122.106.149.109]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 8F9084281F9; Fri, 24 Jun 2016 20:55:02 +1000 (AEST) Date: Fri, 24 Jun 2016 20:55:01 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Peter Wemm cc: freebsd-arch@freebsd.org Subject: Re: PowerPC 64-bit time_t In-Reply-To: <575A48D3.3090008@wemm.org> Message-ID: <20160624194454.D1013@besplex.bde.org> References: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> <20160609193128.GB34204@spindle.one-eyed-alien.net> <575A48D3.3090008@wemm.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=M8SwUHEs c=1 sm=1 tr=0 a=R/f3m204ZbWUO/0rwPSMPw==:117 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=fYwcVdWAvfHp3KS-F6MA:9 a=U6V5D88igUOAZD_W:21 a=EH4GcJ3lJI1tdCgS:21 a=CjuIK1q_8ugA:10 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 10:55:12 -0000 On Fri, 10 Jun 2016, Peter Wemm wrote: > On 6/9/16 3:31 PM, Brooks Davis wrote: >> On Thu, Jun 09, 2016 at 01:41:52PM -0400, Justin Hibbits wrote: >>> At the devsummit earlier today I mentioned for FreeBSD 12 wanting 64- >>> bit time_t across the board. It was pointed out that the only ones FreeBSD-12 certainly doesn't want the bloat and ABI breakage of 64-bit time_t. The 32nd bit is not needed before FreeBSD-23 in 2038. The 33rd bit is not needed before FreeBSD-57 in 2106. >>> with 32-bit time_t are i386 and powerpc (32-bit). I've made the >>> changes necessary for at least kernel (world is still building right >>> now), but it's obviously an ABI and KBI incompatible change. >>> Addressing KBI is a nonissue, as that's expected to break at major >>> releases. ABI is another issue. I'm unsure how to properly address >>> ABI breakage -- bumping libc's .so version, or reversion all symbols >>> that use something with time_t, or something else. If I can address >>> it before the code freeze, it could be done for FreeBSD 11, which >>> leaves about 6 hours from now. >> >> For i386, the only practical option is going to be a new TARGET_ARCH and >> likely ELF machine type. The only practical option for i386 is to change to unsigned time_t before 2038 and hope that i386 goes away before that runs out in 2106. Changing to uint32_t time_t mainly requires doing something with times before the Epoch. These are unsupported in POSIX, but are supposed to work back to 1902 with int32_t in FreeBSD, except 1 second before the Epoch is the same as the error code (time_t)(-1) so it doesn't work right. > I investigated this when I did 64 bit time_t on amd64 - the chances of > getting this to work on i386 are ... problematic.. to say the least. > > A short summary of the issues for i386: > > * sparc64, amd64 and ia64 were "easy" because there was an actual register to > implement it. Calling conventions plaster over vast quantities of sins and > carelessness and make it Just Work by in spite of it. You forget a function > prototype and it still works. i386 has to do it with "long long" which > requires discipline. Miss a prototype and it falls flat. On 64-bit arches, most of the space bloat for 64-bit time_t is unavoidable because: - args are expanded to 64 bits - struct timeval was originally misdesigned as having members tv_sec and tv_usec of type long. These longs were basically an implementation of int_least32_t before existed. tv_usec only needs to go up to 10**9, so it should have type precisely int_least32_t or possibly int32_t to give an invariant ABI. POSIX copied this mistake and added many more when it made the mistake of inventing struct timespec. ts_nsec stil has type long. This gives the stupid ABI that on 64-bit arches with 32-bit time_t, struct timespec starts with a 32-bit time_t, then has 32 bits of padding, then has a 64-bit long with only 32-bits used. Later, POSIX broke the ABI for struct timeval to match -- it changed 'long tv_sec' to time_t tv_sec. So using 64-bit time_t costs little on 64-bit arches. > eg: if you miss the prototype for a function returning time_t the language > defaults the return value to "int". On ia64, amd64 and sparc64, this is > actually returned as a 64 bit value (native register) and it actually gets > the full 64 bit value. For i386, this doesn't happen - you always get > truncation. You won't find out until it actually matters. This problem will > keep turning up forever. The top half will be returned in the %edx secondary > return register and will be ignored. Forever only afer 2038 :-). And between 2038 and 2106, 32-bit time_t will still almost work without making it officially unsigned -- discarding the top half still gives a value that is correct when the sign bit is interpreted as a value bit, provided it was set using overflow magic as a value bit. > * classic 3rd party code used "long" and "time_t" interchangeably. We get > away with this on ia64, amd64 and sparc64 just fine. This will also lead to > truncation on i386 with 64 bit time_t when it matters. > > * Sloppy prototyping leads to stack misalignment on i386 with "long long". > Arguments are rounded up to 32 bit alignment, so char/short/int/long > confusion on i386 for function calling protocol mostly is repaired as a side > effect. 'long long' doesn't get this treatment for function calls - any > sloppiness will be punished with arguments being shifted. Unlike the > truncation above, this is pretty quick to find. You won't have to wait 5-10 > years for them to shake out. > > Most of the FreeBSD base tree was fixed for this during the Alpha era (which > used "int" for time_t on a 64 bit platform because mktime() in libc wasn't 64 > bit safe at all). However, when you go near ports and 3rd party code the > situation is rather grim. The code out there is terrible. > > I maintain that while we got away with it for machines that the calling > conventions masked the pain for sloppy and legacy programming, this is not > the case for architectures like i386. The pain will never end. I agree. > Do you want to be the one who has to explain why something like openssl isn't > rejecting expired certificates because openssl happens to confuse long/time_t > internally somewhere in the X509 validator? (Note: I'm not saying it is > broken, but I don't have a hard time imagining that it could..). The question is if changing 32-bit time_t to unsigned is also too painful. I think it won't make much difference until 2038 when the 32nd bit is actually used. > Also, don't forget all the compat_freebsd32 layers. You'll have to realign > all the arguments because 'long long' is 32 bit aligned, and a 64 bit long > (aka time_t) is 64 bit aligned. Also, they need to do something better than truncation to convert 64-bit time_t to 32-bit time_t. The only reasonable thing to do between 2038 and 2106 is to use uint32_t for the compatibility layers and teach old applications to expect this. Then there are the compat_{linux,svr*} layers. All representations and conversions must be compatible with whatever the emulated OS does. > I'm sure it could be done for a science project, but I wouldn't want to go > anywhere near it for something that would be relied upon. This would be a > project that gives gifts that will keep on giving. Bruce From owner-freebsd-arch@freebsd.org Fri Jun 24 11:07:20 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEDD2B73848 for ; Fri, 24 Jun 2016 11:07:20 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8A4A42CA6 for ; Fri, 24 Jun 2016 11:07:20 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 7EC01273B5; Fri, 24 Jun 2016 11:07:12 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u5OB7ASZ004642; Fri, 24 Jun 2016 11:07:10 GMT (envelope-from phk@phk.freebsd.dk) To: Bruce Evans cc: Peter Wemm , freebsd-arch@freebsd.org Subject: Re: PowerPC 64-bit time_t In-reply-to: <20160624194454.D1013@besplex.bde.org> From: "Poul-Henning Kamp" References: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> <20160609193128.GB34204@spindle.one-eyed-alien.net> <575A48D3.3090008@wemm.org> <20160624194454.D1013@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4640.1466766429.1@critter.freebsd.dk> Date: Fri, 24 Jun 2016 11:07:10 +0000 Message-ID: <4641.1466766430@critter.freebsd.dk> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 11:07:20 -0000 -------- In message <20160624194454.D1013@besplex.bde.org>, Bruce Evans writes: >The only practical option for i386 is to change to unsigned time_t before >2038 and hope that i386 goes away before that runs out in 2106. Changing >to uint32_t time_t mainly requires doing something with times before the >Epoch. These are unsupported in POSIX, but are supposed to work back to >1902 with int32_t in FreeBSD, except 1 second before the Epoch is the >same as the error code (time_t)(-1) so it doesn't work right. I'd recommend it, dates one timezones worth before epoch are far too common in contemporary traffic (particular HTTP). Why don't we make a i387[1] port where time_t is 64 bit and where we jettison the museum-ready IBM PC baggage ? [1] Of course a joke reference to floating point HW being mandatory. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Fri Jun 24 11:10:07 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1FDC8B738C3 for ; Fri, 24 Jun 2016 11:10:07 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id DDA532D9C for ; Fri, 24 Jun 2016 11:10:06 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 945AA273CD; Fri, 24 Jun 2016 11:10:05 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTP id u5OBA54M004659; Fri, 24 Jun 2016 11:10:05 GMT (envelope-from phk@phk.freebsd.dk) cc: Bruce Evans , freebsd-arch@freebsd.org Subject: Re: PowerPC 64-bit time_t In-reply-to: <4641.1466766430@critter.freebsd.dk> From: "Poul-Henning Kamp" References: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> <20160609193128.GB34204@spindle.one-eyed-alien.net> <575A48D3.3090008@wemm.org> <20160624194454.D1013@besplex.bde.org> <4641.1466766430@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4657.1466766605.1@critter.freebsd.dk> Date: Fri, 24 Jun 2016 11:10:05 +0000 Message-ID: <4658.1466766605@critter.freebsd.dk> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 11:10:07 -0000 -------- In message <4641.1466766430@critter.freebsd.dk>, "Poul-Henning Kamp" writes: >-------- >In message <20160624194454.D1013@besplex.bde.org>, Bruce Evans writes: > >>The only practical option for i386 is to change to unsigned time_t before >>2038 and hope that i386 goes away before that runs out in 2106. Changing >>to uint32_t time_t mainly requires doing something with times before the >>Epoch. These are unsupported in POSIX, but are supposed to work back to >>1902 with int32_t in FreeBSD, except 1 second before the Epoch is the >>same as the error code (time_t)(-1) so it doesn't work right. > >I'd recommend it, dates one timezones worth before epoch are far too >common in contemporary traffic (particular HTTP). It's too warm here: read: I'd recommend *against* it. >Why don't we make a i387[1] port where time_t is 64 bit and where we jettison >the museum-ready IBM PC baggage ? > > >[1] Of course a joke reference to floating point HW being mandatory. > >-- >Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >phk@FreeBSD.ORG | TCP/IP since RFC 956 >FreeBSD committer | BSD since 4.3-tahoe >Never attribute to malice what can adequately be explained by incompetence. >_______________________________________________ >freebsd-arch@freebsd.org mailing list >https://lists.freebsd.org/mailman/listinfo/freebsd-arch >To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Fri Jun 24 17:13:31 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F8B9B80D23 for ; Fri, 24 Jun 2016 17:13:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50AC22EDC for ; Fri, 24 Jun 2016 17:13:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0EB55B963; Fri, 24 Jun 2016 13:13:30 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Cc: Poul-Henning Kamp , Bruce Evans Subject: Re: PowerPC 64-bit time_t Date: Fri, 24 Jun 2016 10:12:13 -0700 Message-ID: <2202995.kTBLB6p9Br@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.3-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <4641.1466766430@critter.freebsd.dk> References: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> <20160624194454.D1013@besplex.bde.org> <4641.1466766430@critter.freebsd.dk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 24 Jun 2016 13:13:30 -0400 (EDT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 17:13:31 -0000 On Friday, June 24, 2016 11:07:10 AM Poul-Henning Kamp wrote: > -------- > In message <20160624194454.D1013@besplex.bde.org>, Bruce Evans writes: > > >The only practical option for i386 is to change to unsigned time_t before > >2038 and hope that i386 goes away before that runs out in 2106. Changing > >to uint32_t time_t mainly requires doing something with times before the > >Epoch. These are unsupported in POSIX, but are supposed to work back to > >1902 with int32_t in FreeBSD, except 1 second before the Epoch is the > >same as the error code (time_t)(-1) so it doesn't work right. > > I'd recommend it, dates one timezones worth before epoch are far too > common in contemporary traffic (particular HTTP). > > Why don't we make a i387[1] port where time_t is 64 bit and where we jettison > the museum-ready IBM PC baggage ? The common proposal has been to have a freebsd/i386t64 (or some other name). Technically speaking FreeBSD/i386 is already FreeBSD/i486dx anyway (we mandate cmpxchg and an FPU. We might support an external FPU on 486, but that hasn't been tested in a long, long time). It has been pointed out that we can actually make this work by adding a new Elf ABI and that the i386 kernel could support both ABIs by simply choosing the appropriate sysent. For userland we could have a /usr/libt32 or some such that is built with the old ABI similar to /usr/lib32 on amd64 and powerpc64. You could then "stage" this by providing /usr/libt32 for a while and letting people do a cutover where they set a src.conf knob to switch the "default" ABI from plain i386 to i386t64 (depending on /usr/libt32 to run existing binaries during installworld, etc.). We would probably change the default ABI of the next X.0 release to use the new ABI for i386. However, someone has to want to do this to put in the work. -- John Baldwin From owner-freebsd-arch@freebsd.org Fri Jun 24 19:31:29 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8B69AC49FF for ; Fri, 24 Jun 2016 19:31:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 752A9181B; Fri, 24 Jun 2016 19:31:29 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x235.google.com with SMTP id s63so103722484ioi.3; Fri, 24 Jun 2016 12:31:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pPZVoxAUZebDjpdLKHHVx/af5MKA/X/v9shxyjv2Z2w=; b=oGVXq6uhqMHQRDCriOH2z/ztfuCjSWvpoPLJtR1LSdiYH6+cYumAVMxdAJzevWvq0X jWVCAsH0Xkd23OcWKPqTFbcRtr8leGWWZsLcxe+1pcRlhJi32pyJDb7Ijbq70VL7DItL T3ChLw3pAjS7VLAuJ+Cod15pMff3AhqO6GdZMjs0YeMuByStP+or+3n0IE/IH/QLIIbh 0mf6N57Grv2a34vpq1tzr4gwOkAps0DghE/QKhzkK2Z8Qh46m5A8kIA0lgcVB830VL9Q qowCNBxz9xbBwxGtzAyO1h0i7FaJ/sjESLaK/O0XhhjHPgkAIKXNQu8CX16L35RMuhYt yIeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pPZVoxAUZebDjpdLKHHVx/af5MKA/X/v9shxyjv2Z2w=; b=gyx+SUi1ZCBnifXpVziip9PcYFwjC5O6KJDH4fxZi4eFGK0Q5mREjVVv0cZcOi6GAH gJbcPhknVg8GtSxCrVZVNCUkNbfsmVHrtdmQM6M1DdkzX3XII3uRZFb2mdSF0RfIcZf+ BuKDLMjT4WQ7GV6h5LtNWUYUYPK4ftg7vRQS0DLfluPor2UsrSQ7eTGgsN02YU7cG+9D HaLOszdferJanA5OdR4Ycat2w9wHzuQCAwnZXpEWozNQClmS59TiXfc/RbZPuUrzaw6S fcef21WvYnwVhHYN1S/RVAHKS2UxgMYvDINmTrHtZEY3AYjdFbV/UL6kHYQ+rKys1hIs 8g0w== X-Gm-Message-State: ALyK8tJAkhjShN0viu/yqLNTHMomPF3HqJIVhkMco8WDsxvnvACcLa+SwQcZzxaLcwrFujbBTkOeDDD3rV5hxg== X-Received: by 10.107.16.24 with SMTP id y24mr7112698ioi.123.1466796688814; Fri, 24 Jun 2016 12:31:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.210.212 with HTTP; Fri, 24 Jun 2016 12:31:27 -0700 (PDT) In-Reply-To: <2202995.kTBLB6p9Br@ralph.baldwin.cx> References: <3FB65E20-0376-4041-86DE-F8CAB7F37314@freebsd.org> <20160624194454.D1013@besplex.bde.org> <4641.1466766430@critter.freebsd.dk> <2202995.kTBLB6p9Br@ralph.baldwin.cx> From: Adrian Chadd Date: Fri, 24 Jun 2016 12:31:27 -0700 Message-ID: Subject: Re: PowerPC 64-bit time_t To: John Baldwin Cc: "freebsd-arch@freebsd.org" , Poul-Henning Kamp Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 19:31:29 -0000 [snip] We could just call the architecture i486. :-) -adrian