From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id AC6EE1F462 for ; Mon, 29 Jul 2019 17:47:11 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:cc:references:from:subject:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=JxMicY+v1cEeO9LY PTK1qiDuYZCMl4mFkRLs00NqjV9dqUBF8d6CeSyU70UObRfQe+O7crOL3AkICpMh DaOtfk4sBwIQiBV86It+qA9uGtpXceTVLccI5+1djG4Srf2+9NoaoizLMYfmD09x 1YtVpZOt7HZm0WgT89JXnfnQv4k= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:to:cc:references:from:subject:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=1qvHxHzoReadKSLfHWddFo Vt/Ac=; b=yPUFhVwszxLxyQx+mkVMnAcn2UHsAOyi6G8XQleAiuVVWWDHg13NQH sDE+ITZO9wXNVl92dRn6DykT0ZJoFPz/zm4gpd0cHoO1cAPVG1S6AFYS7pW7bbBX kevVwLYH9AdT7vPJFYrTNxCfpkrgNiJjRz2A8ztYDtfUQSg37afAU= Received: (qmail 42463 invoked by alias); 29 Jul 2019 17:47:09 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 42455 invoked by uid 89); 29 Jul 2019 17:47:09 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qt1-f180.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:cc:references:from:openpgp:autocrypt:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+D2K2Y5XubTjdXWXVuwoBLkOoDPKN23pxf7I6g7sDgc=; b=UXhLRFeLRzcNUo5UD9o6PHyozFoexgvjEyf4mtqy7Cgoh62PeRZGhbQ2awS+hAbsCL FW1NXwF7AIiDcLvWDf4/ktMfIFRK6ZUWoKUlas7Kbgsxub8dK3Ij5bV1E4zpDNzHpA7C RQmxzKK4LecrDJEEQFK+L9gSE0ej/B0oikcRvMf/RGIbVAxPECsZhOHc+8VJc6wz+Zug eq1GsM6cK6ddNYFNnjO/2WykXHmsvXhxkC8ONBjN94GyW5OHi18NVzWOf5DnoCir2Aqd bXeOivY11zBadxtdS9m/7bil5uOLbVnVgaDdU7lL+1ePnwxHSL9SnjCIcX2RH35ewkgE S7aQ== To: Joseph Myers Cc: libc-alpha@sourceware.org References: <20190712072103.D3DBC24003A@gemini.denx.de> <874l3mjgi6.fsf@oldenburg2.str.redhat.com> <20190716145216.1C7CE240085@gemini.denx.de> <875zo0911b.fsf@oldenburg2.str.redhat.com> <20190717160021.75EB224003E@gemini.denx.de> <87h87k7ilf.fsf@oldenburg2.str.redhat.com> <20190717181811.5902cd5e@jawa> From: Adhemerval Zanella Openpgp: preference=signencrypt Subject: Re: Accelerating Y2038 glibc fixes Message-ID: <43e70b10-c1a1-ca79-b596-60616c8f5ad6@linaro.org> Date: Mon, 29 Jul 2019 14:47:01 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 25/07/2019 17:40, Joseph Myers wrote: > On Thu, 18 Jul 2019, Adhemerval Zanella wrote: > >> So what about to not add a user-selected way to set the time_t size >> (as off_t) and just enable time64_t support and sets is as default for >> build with a minimum kernel of v5.1 (if I recall correctly as being the >> one that added time64 support)? > > I think duplicating ABIs like this is a very bad idea - the ABI supported > by glibc for a configuration that currently has 32-bit time_t should not > change to have two different, incompatible variants depending on how glibc > is configured. The default API provided by glibc should also not vary > like that depending on how glibc is configured. Later on the thread [1] I did state I would prefer switch based on release rather than a configure option, the suggestion was initially as a way to easier the transition (at the cost of complexity I give you). > > Given that you have compatibility with existing binaries (as opposed to a > complete new incompatible libc.so.7 ABI with building libc.so.6 for that > architecture ceasing to be supported by glibc), eliminating support for > building with _TIME_BITS=32 makes the changes much *harder*, not easier. > There are three logical steps in the time_t transition. > > (a) Support building applications for 64-bit time_t, using _TIME_BITS=64. > > (b) Change the default to _TIME_BITS=64 (also requires defaulting to > _FILE_OFFSET_BITS=64). > > (c) Remove support for building applications with _TIME_BITS=32. > > The hardest of those steps is (c), not (a), because of the difficulty in > both building and testing all the compatibility symbols after step (c), > without all the header redirections of symbols getting in the way when > building those functions and the tests for them. > > In view of the difficulty of both (c) and (a), it clearly makes sense to > separate them, and start with (a), with (c) to follow some time later. Since we require to have both time32 and time64 implementation for the 'legacy' 32-bit architectures, the change to implement (c) is mainly to make the symbol compat ones. And since we will need to internal logic to select whether to build time32 implementations (since for newer 32-bit ABI time32 is not a option from kernel side and it does not make sense to add time32 interfaces for such cases), the same applies for make them a compat symbol. The tricky part is testing, where it would require some more boilerplate to redirect to compat symbol instead of just define the _TIME_BITS, but with proper infrastructure on libsupport I still think this is feasible. One extra step we will need to implement is to extend the abilist to take in consideration whether the symbol is not the default version. So I am not sure if (c) is really the most difficult part of the required changes. The question I have is what is the real gain of still supporting _TIME_BITS=32 as a build option, if the idea is default to _TIME_BITS=64. It open a possibility to programs that are not time64 ready to just add _TIME_BITS=32 as a workaround, which is clearly *not* the desirable long-term desirable option. > >> I also wish we could also move forward with off_t and set LFS as default >> as well. > > We can (it's the equivalent of (c), not of (b), that's particularly hard, > though even when doing (b) you need to be careful you keep sufficient test > coverage for both function variants). See what I said in > . > I recall the thread and your suggestion as the guideline to move forward [2]. However the getdents64 regression (BZ#23960) shows us that even after two decades, at lot of environments still don't use _FILE_OFFSET_BITS=64 as default and it most likely will take even more time to actually make it to land of some projects. This is most likely the usual usercases don't actually required LFS support and only handful scenarios might trigger some issues with non-LFS support. And *now* is true for time_t interfaces as well, programs will continue to be build and deployed with default options, or even worse, some pieces will be build with different time_t abi which IMHO it even more difficult to debug. They will move forward to a safer ABI only when things start breaks. So, different than LFS, I see no point in not moving forward to time64 and just make time32 deprecated/compat. [1] https://sourceware.org/ml/libc-alpha/2019-07/msg00456.html [2] https://sourceware.org/ml/libc-alpha/2019-01/msg00177.html