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=-4.0 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 BE8A71F461 for ; Wed, 17 Jul 2019 14:41: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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; q=dns; s=default; b=QK2fW WinIAZD688MPLQRWcp+UkEYKI/GJUlb7M85MDQHiFjrIyKd3mGg0YFky3HHl9CaJ Y4beBo70EkLB8Q5VKqi27fUtqCXKyaoK22jruhamENnvf+PevNxiX0Ma9u/S8sSL yJ8cSBFXxY5/iViwQCrv2s1XxiUg3AcD103n10= 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:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; s=default; bh=+rIHfImK7Hz n8Jg0AVkXYl98em4=; b=nEyYk6DcF0u9GxrT5g45S9/tXMGqS+O3gWtEgXEoX3F S2JAaNFRzN3PAV6GgLk5ixDx4DdFFw7DY0CuA2SukoQnddpsY3EelPJjYor0sFZ0 tBXREk3MiA/08lz9K7QPvibk1Mc40FTJI9ugZz9nx7FQLOHOgBFfSEsD0VywC4GE = Received: (qmail 67858 invoked by alias); 17 Jul 2019 14:41: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 67850 invoked by uid 89); 17 Jul 2019 14:41:09 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: Arnd Bergmann Cc: Wolfgang Denk , GNU C Library , Lukasz Majewski Subject: Re: Accelerating Y2038 glibc fixes References: <20190712072103.D3DBC24003A@gemini.denx.de> <874l3mjgi6.fsf@oldenburg2.str.redhat.com> <20190716145216.1C7CE240085@gemini.denx.de> Date: Wed, 17 Jul 2019 16:41:04 +0200 In-Reply-To: (Arnd Bergmann's message of "Wed, 17 Jul 2019 16:15:25 +0200") Message-ID: <875zo0911b.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain * Arnd Bergmann: > b) Those that already need support for 64-bit time_t because > they are deploying new 32-bit binaries that are expected to run > beyond 2038, while not caring at all about compatibility > with existing binaries that are already known to be broken > for this purpose. There is also c), new 32-bit architectures which need 64-bit time_t support today due to kernel limitations. Whether those binaries need to run for two years or twenty does not matter to them. I have reviewed patches for the c) case, but that doesn't seem to be work that interests Wolfgang. > Any of the above approaches (including the current plan of > supporting time32 and time64 in a single glibc binary) can of > coexist, but the more incompatible approaches get implemented, > the more fragmentation of ABIs we get. > > Note that we have never had such a forced transition on x86, We did change the stack alignment requirements on x86. Without any ABI markup. For the non-executable stack, we used proper markup, but hat approach will not work for time_t. Several of the transitions you mentioned have ELF markup for the transition, and at least in the case of ELF v2 for POWER, it is really clear and consistent (it's also an easy scenarion admittedly, and very different from the time_t situation). Part of my reservations about the update to legacy ABIs is there hasn't been any discussion about markup. I'm not saying that we absolutely need to have it. It's just something that contributes to my general unease. Thanks, Florian