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 481C21F462 for ; Mon, 29 Jul 2019 21:00:38 +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=rVTnWxXaNyou9nBT kpGhJ3E7/Clm1xW8/d6GIb426GRojfZJkyPV5hwZ9U1OVWQ7VIYaGNJsEf0gFKSq fY2jKaZrHgSd8+e2vOBbQCDH9G/yU/AQ0ZL73+whGBkw/vMYKt0bjWKztLneK1Cw Nv3isKzm11W6o8Fd27ssqMVAM40= 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=ffZT581XWOV0ufeJQRmZqf MgSGg=; b=ZsAsoLfKPZ44vli3VuLXgDRYDIaTEjty8Qn0Pt1gVIrqddPbSwn8VS oB7+ihTedRnQTylfS6Y++sXuC5hNagnVL4ybNXxSgqZIZf9VWNiT1rIW3drGYFfH r2bbe37noZLgKdcRJENo5DoXAdPbw04YetcWlsAUUACGCSVLfviqA= Received: (qmail 44096 invoked by alias); 29 Jul 2019 21:00:35 -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 44064 invoked by uid 89); 29 Jul 2019 21:00:34 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qk1-f193.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=xU7i2MKLDHTzIfjGXfEn781VdsOBuKnho0RYLbZJYRE=; b=mF8MA2OcazwzYTsW/Le5KIpONADEX3EuUNQ1Rpp0CCDwL2d0tX9eijhOeP53sQ+vwJ Zfw5zWReSXYFI6jPMc8G4Imj+WbmNA46fs+rpu2m23+9g94UlwyJujaZGZ4bQmBzquue 7pSjVd0PrY+ZeQYCn1q6HMnXKqYaBMbFGEJb3TSyk2JWttRE9TQntWDZ9+hbxVm4nHPH 5MEbbNFWu2qQrwrekkWWmUG/8DK2taffVAqBkIjrYaDfoIVJH3ylGY1mfXw4iO5FXX3b kLi7olbblb0AwS4Rxy37RGhQLCzxK4ewY9PI6Kib5J0gj6d0NW/jwBuNpondH24ly5yp D3qA== 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> <43e70b10-c1a1-ca79-b596-60616c8f5ad6@linaro.org> From: Adhemerval Zanella Openpgp: preference=signencrypt Subject: Re: Accelerating Y2038 glibc fixes Message-ID: Date: Mon, 29 Jul 2019 18:00:25 -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 29/07/2019 16:58, Joseph Myers wrote: > 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. To make the time_t change its type on a new glibc release rather than the configure option. > >> 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. I think it would be easier than what you described because we won't need to actually to add any header redefinition, all symbol affect will just use the new time_t regardless of the ABI. The compat implementation will use an internal-only type to use the old one. What it would require is to add compat implementations with a different type, time32_t for instance. Something like: --- * sysdeps/unix/sysv/linux/generic/bits/typesizes.h [...] #define __TIME_T_TYPE __UQUAD_TYPE [...] * time/time.h [...] extern time_t time (time_t *__timer) __THROW; [...] * sysdeps/unix/sysv/linux/time.c [...] time_t __time (time_t *t) { #ifdef __ASSUME_TIME64_SYSCALLS return INLINE_SYSCALL_CALL (time64, t); #else int ret; # ifdef __NR_time64 /* Maybe we can use 'sets' of 'supported' to enable/disable multiple syscalls. */ static int time64_supported = 1; if (atomic_read_relaxed (&time64_supported) == 1) { ret = INLINE_SYSCALL_CALL (time64, t); if (ret == 0 || errno != ENOSYS) return ret; atomic_store_relaxed (&time64_supported, 0) } # endif /* __NR_syscall64 */ ret = INLINE_SYSCALL_CALL (time, t); /* I assume kernel will return EOVERFLOW if the case. Other symbol will require further handling. */ return ret; #endif } libc_hidden_def (time) /* At first it would be a arch-specific definition, on kernel-features.h. Maybe there is a clever way to accomplish it. */ #ifdef __REQUIRE_TIME32_COMPAT /* Define time32_t internally somewhere. */ time32_t __time32 (time32_t *t) { return INLINE_SYSCALL_CALL (time, t); } compat_symbol (libc, __time32, time, GLIBC_2_0); versioned_symbol (libc, __time, time, GLIBC_2_SOMETHING); #else weak_alias (__time, time) #endif [...] --- I used the simplest symbol I can think off, other symbol that use time_t embedded inside more complex struct will need to replicate it on some compat header (as we do for some internal definition such sigaction). Testing will require more boilerplate to link against the compat symbol, but we already have some support on libsupport and I think we can improve to make it simpler. > >> 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. > I don't have a strong opinion if a patch proposal use the _TIME_BITS=32 as a initial transition to enable time64 support, however I see no point in make it available either on a release point neither in long term. In fact I see that support_TIME_BITS=32 on long term is a detriment for the ecosystem as whole. It is error prone, it will be glibc specific (since other system that used to have the same issue already did that transition without similar complexity, such as BSD), and it will lead to subtle bugs with the multiple build systems that we have in Linux ecosystem. That's why I still think that an initial rough transition now to move forward definitely is better than still support broken interfaces indefinitely (not considering the required compat implementations).