From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x31.google.com (mail-oa1-x31.google.com [IPv6:2001:4860:4864:20::31]) by sourceware.org (Postfix) with ESMTPS id 4D0F43858D20 for ; Fri, 3 Feb 2023 14:17:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4D0F43858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oa1-x31.google.com with SMTP id 586e51a60fabf-15ff0a1f735so6773817fac.5 for ; Fri, 03 Feb 2023 06:17:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=8C6I7IWATLBKIt5JuHvuO12TlCoBMCC+cs135udb7Ic=; b=c+dVkK6Pelrbl+k356AxOkMbyxaC1SK4oL+I9izES7ijAs/IFPIrSPjBsiq1tcTfLx pmqEufO+yVW1QIyyDEjH/DHdVLmVb6gxZHURmPXBkucgiP3tt71tDyumgmziFZidS5aH byM9RVGIH+bMb3lvAEHY2QKVd7bzBKB6/oKBzA2z9jF/D4BfZQtvvT1EUFK1qQE9DVBy FYJvPNezRV0Udn/U5adOBN0zGC8Xc1LS4788JVf9FB7NcrL7vo02LSNs3dsEPx24lIAa zAPsEY72bKA0YHCdkZ8QFXYLDeKXinidVTeFhEl1mzyoaJ0CMFvNfP8GJcKHIqBQrFmu rYaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=8C6I7IWATLBKIt5JuHvuO12TlCoBMCC+cs135udb7Ic=; b=sSioik80vPCbKtolFIUbLUt88oDrBnja9gEg3PP1T1/lE24GD/YbNvgZmV2ehno3l4 vjZ/nxthZm0xjog2gG9SfW9op+ZaQSropTz3MgxWeAvmKDVHsgniP9pTcvgGUWycrq9j JHhFT5rL/56jLdGdmBpXNf8uMhzNlhEe785PeWE2asSBve6Emuy5GMRfpEWVW0WxINJT x7RsU2waqaBE7gOBnyPyafvx5DYhtiPAoJPZ5G/QXxQh8Ps3WQzv9njpuOGLx5DzPYRH WCvn566rHikowy3goEGF6xxxOe6HCV2ZJTAb6nEK3d8HO2PSmCBKKEUTkW8tRQCowAWE IS+g== X-Gm-Message-State: AO0yUKXi7rZhDbGl3EPRb+vqNwMYy2z692U+/mp8wTx8c4WUrJXSbLj8 7nTMcyyPgEskqSmrS6e+0UVS+g== X-Google-Smtp-Source: AK7set/aBAKEdF1CySGgGWC7PKEd4/RmuDWQyx3AGSQfu9bNXwdbQnQGx8utWAud1Dn7fCG/Xwgs3Q== X-Received: by 2002:a05:6870:c1d0:b0:15b:aa45:ae50 with SMTP id i16-20020a056870c1d000b0015baa45ae50mr7493897oad.53.1675433848556; Fri, 03 Feb 2023 06:17:28 -0800 (PST) Received: from ?IPV6:2804:1b3:a7c2:1887:71e4:6a44:32a:be62? ([2804:1b3:a7c2:1887:71e4:6a44:32a:be62]) by smtp.gmail.com with ESMTPSA id k20-20020a056820017400b0051751ab5a7csm1036896ood.2.2023.02.03.06.17.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Feb 2023 06:17:27 -0800 (PST) Message-ID: Date: Fri, 3 Feb 2023 11:17:24 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.7.0 Subject: Re: time64 / Large File Support: 2) default time64 breaks legacy 32bit binaries Content-Language: en-US To: Michael Hudson-Doyle , Florian Weimer Cc: Sam James via Libc-alpha , Sam James References: <10857996.18pcnM708K@pinacolada> <7196595.N7aMVyhfb1@pinacolada> <7271eb94-b5d7-69d6-9be0-ca1afda29a50@cs.ucla.edu> <2342ab66-6ac6-17d8-3693-8e2fd93fc8a1@linaro.org> <87bkmdwdv8.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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: On 01/02/23 19:22, Michael Hudson-Doyle wrote: > On Thu, 2 Feb 2023 at 05:27, Florian Weimer via Libc-alpha > wrote: > > * Sam James via Libc-alpha: > > > Right, it seems RH has some needs due to supporting existing > > customers, but I don't think this should unduly affect what glibc > > upstream does if there's one clear technical path forward. Nobody > > seems to actually dispute that the end-game here is a hard switch at > > some point. Just about when. > > I'm mostly worried about the glibc project issuing a statement that > distributions should change the i386 ABI of libraries layered on top of > glibc.  I don't quite see how this is in anyone's interest. > > What's the reason for a 32-bit x86 distribution at this point?  Support > for old hardware which can't run 64-bit binaries?  Running 32-bit > binaries which can't be rebuilt?  Optimizing the footprint of workloads > that fit into a 32-bit address space? > > > The only reason Ubuntu still builds any packages on i386 at all is reason 2 here, to allow people to run old binaries that can't be rebuilt. As time passes the binaries that people care about are increasingly games. I presume for the cases where y2038 matters the default solution will be to run these binaries in a namespace that lies about the time. It is an option, although I am not sure what might really work since afaik Linux does not support CLOCK_REALTIME on time namespace. > > Only the first reason (old hardware on current distributions) can > justify the ABI bump.  And it's in direct conflict with the second > reason. > > > Exactly. >   > > For the third reason, it may be more approriate to revive the x32 port. > At least it doesn't interfere with legacy use.  There's a non-upstream > ILP32 port for aarch64, too, so the largely the same choice is available > over there (although 32-bit-only CPUs that may run glibc code are still > being manufactured in the Arm ecosystem, so the tradeoffs are different > over there, I assume). > > > The 32-bit arm would is an entirely different calculation, yes. There are definitely devices being manufactured today that run Linux 32-bit that have the sort of expected lifetime that will bump into y2038 issues. I really hope the manufacturers have a plan! OTOH, there isn't a large pile of old armhf binaries lying around that people want to keep working in the same way there is on x86. > > For people who use yocto or buildroot they should just start passing -D_TIME_BITS=64 and rebuild the world but general purpose, package based distributions have a more delicate dance to perform (FWIW, we don't have a fully fledged plan for Ubuntu yet but we're certainly starting to think about it). >   > > My hunch is that the most likely outcome of switching distributions to > 64-bit time_t is that the i386 port goes away more quickly than I would > expect otherwise because it makes the port rather useless for most > existing users (especially with those distributions that no longer > maintain a 32-bit-only kernel).  Personally, that wouldn't be a bad > outcome at all for me.  But I doubt that this is what people who push > for this change have in mind. > > > Is anyone proposing that glibc will lose the ability to have the 32-bit time_t ABI? As you note that would kill the Ubuntu i386 port entirely (at some point this will probably happen anyway, people can always play their games in VMs but still). > Not really, there are some idea on how to proceed with 64 time_t promotion: 1. Add a configure option to enable LFS and 64 bit time_t support as default. It is basically promoting the port to a new ABI, although a program can still build with non LFS or 32 bit time_t by explicit use -D_TIME_BITS=32. 2. Make this option the default on a future glibc version, meaning that for distribution that want to keep the the compatibility mode as default (to run old binaries) will need to explicit enable it. 3. Move the non-LFS and 32 bit time_t symbols compat one, meaning that newer binaries won't be able to use them and -D_TIME_BITS=32 won't be supported or just be a no-op. The 1 and 2 should not be cause many trouble, even if 2 would make 32-bit time_t opt-in. At least it would focused on glibc itself, meaning that a distribution could just ignore the transition by just adding a configure option on glibc build. The 3. is what might cause i386 (and any 32-bit port where ABI also supports 64-bit) to wither. I don't have a strong opinion, maybe we should focus on only the 1. and 2. and see what community things about 3.