From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cheddar.halon.org.uk (cheddar.halon.org.uk [93.93.131.118]) by sourceware.org (Postfix) with ESMTPS id 5DFA73858C29 for ; Sat, 12 Nov 2022 04:20:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5DFA73858C29 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=wookware.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=wookware.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wookware.org; s=cheddar; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:Cc:To:From:Date:From:Reply-To:Subject: Content-Transfer-Encoding:Content-ID:Content-Description:X-Debbugs-Cc; bh=5LyBW14VnYbakfIvZ8ERuzMxKN1hakfjiNn0vn4CDHM=; b=awQZZAIbGQXWKBMGK5fUHql4k5 bBD8ED4hDEs6quSOLzNHsuy9056zrCwY9OfbBYonyDp8GsHYAOQx48EbgciZiNdtsbSht7y++1dxT JPSDwiry7aEZBCxozWWRE7RqH0wsKBAqi46A97ZreuFI9pH3o8PsoG9w7qfjSQj7fcmu/gKZWGeRV Asa0iDjarGxG7IjUQA5g5PFk9IhQV4STAL21bb2VfBY51YdM4y6qMMY2n/eqS5XzcFDL5fcezRheK vDF05QzMqRx7e3lls8m8wPPQWtLVw5oExWJzGK5BPBGg8wo+/Aucl5jAzSEPMon4TsYQuuQAqmDTI izY9jJAQ==; Received: from wookey by cheddar.halon.org.uk with local (Exim 4.92) (envelope-from ) id 1oti0i-0002uG-HJ; Sat, 12 Nov 2022 04:20:52 +0000 Date: Sat, 12 Nov 2022 04:20:52 +0000 From: Wookey To: Florian Weimer Cc: Sam James , Carlos O'Donell via Libc-alpha , autoconf@gnu.org, c-std-porting@lists.linux.dev, Zack Weinberg , David Seifert , Gentoo Toolchain , Arsen =?utf-8?Q?Arsenovi=C4=87?= , Paul Eggert , Frederic Berat , Arnd Bergmann , Helmut Grohne Subject: Re: On time64 and Large File Support Message-ID: <20221112042052.GL27919@mail.wookware.org> References: <87wn81q254.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="0UKK28zE3bJc0fm6" Content-Disposition: inline In-Reply-To: <87wn81q254.fsf@oldenburg.str.redhat.com> Organization: Wookware User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0UKK28zE3bJc0fm6 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2022-11-11 10:19 +0100, Florian Weimer wrote: Hi. I've started looking into the 64-bit time_t transition for 32-bit armhf in Debian. We are currently doing a preliminary bootstrap to see what breaks. We strongly suspect that only a wholesale rebuild for the new ABI (i.e a new Debian architecture) is practical, but have not yet entirely ruled out attempting a migration within the existing armhf arch. A test of this in 2020 by Arnd Bergman found that too much stuff was broken. https://lists.debian.org/debian-arm/2020/02/msg00024.html Things now look much more mature as some others have already fixed various = things. https://lists.debian.org/debian-arm/2022/09/msg00012.html https://lists.debian.org/debian-arm/2022/10/msg00020.html I've not got far with bootstrapping but had got as for as noting that LFS and 64bit timet are tied together in glibc (setting _TIME_BITS=3D64 requires setting _FILE_OFFSET_BITS=3D64). So that's two lots of interacting ABI changes, which doesn't make things any simpler. > * Sam James >=20 > > In Gentoo, we've been planning out what we should do for time64 on > > glibc [0] and concluded that we need some support in glibc for a newer > > option. I'll outline why below. > > > > Proposal: glibc gains two new build-time configure options: > > * --enable-hard-time64 > > * --enable-hard-lfs I don't quite follow the logic of this. glibc already has build-time macros= to set these two things: _TIME_BITS=3D64 _FILE_OFFSET_BITS=3D64 why do we need configure options too? > We should define new target triplets for this if it's really required. We have been coming to the conclusion that this is necessary. If it's not feasible to migrate with the existing armhf (and maybe i386) architectures, then we need a new triplet to define this ABI and (in debian, match the dkpg arch name). > We need to support legacy binaries on i386. Few libraries are > explicitly dual-ABI. Whether it's safe to switch libraries above glibc > to LFS or time64 needs to be evaluated on a per-library basis. For most > distributions, no one is going to do that work, and we have to stick to > whathever we are building today. Well Debian has started this work. > > These would hard-enable the relevant #defines within glibc's headers > > and ensure that any binaries built with such a glibc have both Large > > File Support (LFS) and time64 support. > > > > I've come to the conclusion it's infeasible to try handle the > > migration piecemeal. Various mismatches can and will occur (and while > > it's more likely with time64, it's possible with LFS too) [1]. Right. This is definitely a problem, as both items will be in structs that are exposed in ABIs in various places. What I've not yet got a handle on is just how big a problem. Debian has done large ABI transitions before within an architecture (glibc5->6), (GCC 4.0 C++ ABI), and (long-double transition (from 64 to 128 bits), on a subset of arc= hes), so it is possible. (That long-double transition is the most like this transition, because it involves types that can appear in C and C++ ABI). https://lists.debian.org/debian-devel/2007/05/msg01173.html > > We're now (possibly) on the eve of an autoconf 2.72 release which conta= ins two changes > > of note [2][3] > > 1. addition of a new AC_SYS_YEAR2038 macro; > > 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038. Which is the opposite way round to glibc, where _TIME_BITS=3D64 requires _FILE_OFFSET_BITS=3D64, but not the other way round (_FILE_OFFSET_BITS=3D64, can be set on its own). Am I misunderstanding some= thing here? It doesn't seem right to me that AC_SYS_LARGEFILE should imply AC_SYS_YEAR2038. What is the reasoning behind that? > I really wish the rest of GNU would talk to glibc maintainers before > overriding glibc maintainer decisions. If we cannot revert this in > autoconf (and gnulib), this will very much endanger the Fedora i386 > port. Debian will probably be impacted in the same way. I need to read around all this as I have only just become aware that the LFS thing is entangled with the timet_64 thing. Is there a good place to read _why_ one implies the other? It definitely complicates matters. > > On reflection and after extensive discussion within Gentoo (although > > I don't seek to speak for everybody there) - with special thanks to > > David Seifert and Arsen Arsenovi=C4=87 for tolerating my bikesheds on t= his, > > we don't think it's feasible to handle this in a piecemeal fashion - > > at the very least not without spending a significant & for some, > > undesirable amount of time on supporting "obsolete" 32-bit platforms. Distros need to co-ordinate on this. If there are going to be new triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on them and use them. If distros are happy to migrate to these ABIs within the existing arm-linux-gnueabihf and i386-linux-gnu (or i686-linux-gnu) then we should do that. If half the distros migrate within the existing triplet and the rest use a new one, that sounds like a recipie for much confusion. I could write more, but I'll swot up a bit first :-) Wookey --=20 Principal hats: Debian, Wookware, ARM http://wookware.org/ --0UKK28zE3bJc0fm6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmNvHx4ACgkQ+4YyUahv nke9eg/9ERDfrk8vWLYb5r7wlZjwwJNZQrCIHFbIobNnKwuN5XuPa4YKBEtfpMNi hvMjDL4+ykGT4vcGly6Stsz6ROJRLsnOzfYN+3m24FYB8J4gICpc9uzvSTz90Xu8 j/1N9Tt3WmbYuf0cD8dERgrYXebnaSyuVvEqppeuzzWjE8Ox2v/93EdMSlArV4eY /D++EEALeTzhzS5PP+AmfbXr9fnk0hB48dQWUK3oQOHUDOWmA1iPSzWxtW5n2hJq 7u0ysrqtAbPKsaWSN/OYcKY+PbuvUZ+aWYMHo8v77CJHA0n4Y0WZ99ELt+Z/vybZ dQ5YnEgbHWzcGFq0tPmCCQtEpmLIbcJvpwKC3CvhApNwZDqLqvin9oAkMMToNGb6 CKzUmQcxeMuZJrULs8pgBZIdXGQAe8BgRkjrjphFMsKttJPAvukFJpjAGpnu0x6e It2f9REgfjiMCR7My2XR+dlvwkDqG8vqelxW/HHybRGTc4KhHBpXOfQ8u+DLgA1G tvnwsGGcncdUgpDBJ1jar2VYwfD0VKkjI3Ln17L3r8Kjslb7Fpn9e2+uQLw9AY9n kiTqBwfKPi46duPme4tWLd8Cf8mA5nvA98mUL5qSJFIZLSyZvrJQpaLfxVPQrE1m 4ayDjJE0ZcPwNHlAYxK7InVwm3d6f3dE8uFA4zkQRYQbkdPeKr8= =wH11 -----END PGP SIGNATURE----- --0UKK28zE3bJc0fm6--