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 DC84A1F462 for ; Mon, 29 Jul 2019 19:58:20 +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:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=lY6hN AcoKK+iqeeRiWnWXNOWoEBS3DfdpGLHuvWluT/VaWvJzE0vrS1/OOWmqhQmLJNmQ Kh/0uwpOt0Rw7APMJZ/s5i8J/8S3yrm6NX+w9M7fJChI3nrVADx0VRse8UUz9S5k uuZQ4or7K86IrW2iCx4TMijSaDb3vMGQRdejsE= 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:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=gu9j1aDoCQZ 76bUj2x8e6BJ+fvw=; b=xrIn/QZSmqys2ja3BiGoyr6eHEDnVQe4hcfoF0Yuh9n rHPfUyPSHC1nhdJVMsvQrhImwbvL2uVXGs+eIWfd2YGAgk0DZwVXzJGB3MgVq8Xj egMzPfQpgNSdXWTKFPo6bPAVmnn3CkQuZ2tX7+UXedqgagS8g2rHypgvqZXXywBI = Received: (qmail 73170 invoked by alias); 29 Jul 2019 19:58:18 -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 73156 invoked by uid 89); 29 Jul 2019 19:58:18 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: relay1.mentorg.com Date: Mon, 29 Jul 2019 19:58:11 +0000 From: Joseph Myers To: Adhemerval Zanella CC: Subject: Re: Accelerating Y2038 glibc fixes In-Reply-To: <43e70b10-c1a1-ca79-b596-60616c8f5ad6@linaro.org> Message-ID: 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> <43e70b10-c1a1-ca79-b596-60616c8f5ad6@linaro.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" On Mon, 29 Jul 2019, Adhemerval Zanella wrote: > > 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). I'm not clear what "switch based on release" means. > 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 No, it's mainly (for a large number of functions) finding some way to avoid the unconditional (for platforms with __TIMESIZE == 32) header redirects from to ___time64 applying to the definitions of those compat symbols (and, likewise, for all the functions that have variants for _FILE_OFFSET_BITS=32, because we don't want to support the combination of 32-bit offsets with 64-bit times, and requiring 64-bit times implies first requiring 64-bit offsets). You can do that with a suitable #define before including the header and #undef after, but there are many functions, and different implementations of those functions to deal with - and then there is the testing issue, where the changes are probably even more involved. Just adding new function variants with new names and header redirection to provide optional support for using them is much simpler than anything that also obsoletes the old functions. > 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 The gain is supporting building glibc itself for such configurations without a large amount of complicated work to build and test compat symbols needing to be done up front - allowing the transition to be broken down into more reasonably sized pieces. -- Joseph S. Myers joseph@codesourcery.com