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.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_GMAIL_RCVD, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,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 5511A1F461 for ; Fri, 19 Jul 2019 19:07:15 +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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=MGCQ ERrCF+6a6wQL18Cbtg53+nklZGeA/WlZfdJkHv2ZkPuBecOxrXVjcO4+gmVE32pU KVyt3lNF8scZ14RjcEXa7lECXkVQDWn6hzox4+CKAaaYuF+rgcNYwfhW/6utzGWq 3yE/iBQLz00dq57I9wChqx3Rvxbg3zQABFOE1Ng= 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:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=k/01asY+nr bYo5JCzBrYnmTSQJ0=; b=qyn56tycsVF0iGwFaaYgpBZFblRtxAAIcHTyOyBzaS AUuiqU4oF7INJgtR4W3GdWo8CNrC/iuJ8nXKwJrDT8hdtWgmzDpP+p3Ze3W5jesI 9XbLYsnO0Dc6ZJGt22AOUcz8I3VRAhs675dPaUtIIF6O4+J8pj+WHCv6Le4Ba+/C 8= Received: (qmail 62500 invoked by alias); 19 Jul 2019 19:07:12 -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 62489 invoked by uid 89); 19 Jul 2019 19:07:12 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-io1-f67.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=erwh5mCa3z74acoGlfyHV0XpI19tIPRjNgz77+7Pfxk=; b=QHOZXEF+tqmnENubKh8WyOXLYz9QFCI4lngADDMmP0WQhiuZREypjfnoTUz2AaQLjK JKuyhpe+TmRGJWnxhBizlrCZHt84ABUVZFKdBsZZ6m+kSLMovdgFSNjIbUmxjXw3RXZ2 XzBhBl6iCeK2cGBQPbXNF159yQOF0s9izQMhXaHM59S/Rxclu4k2DpcmciwydTx1PAeC aCMkc5sbx6Tu7yQ7KOeZE5VI3iWaJ6uwZfMfqBW+zHJKJUYPrBstHHgOwcTVyMIfqr0q Jpzw72BNsWKkAEWysryAhZXn+hpqQIQ25aVWaNaJ1eHgK+JhIwxeHHR34h/WAoTUmtcJ tFDA== MIME-Version: 1.0 References: <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> <87ftn3xija.fsf@oldenburg2.str.redhat.com> <0a59e20b-e941-e71a-5d4c-cda8088617c3@linaro.org> <20190719030639.GV1506@brightrain.aerifal.cx> In-Reply-To: From: Alistair Francis Date: Fri, 19 Jul 2019 12:03:46 -0700 Message-ID: Subject: Re: Accelerating Y2038 glibc fixes To: Adhemerval Zanella Cc: Rich Felker , Florian Weimer , GNU C Library Content-Type: text/plain; charset="UTF-8" On Fri, Jul 19, 2019 at 10:44 AM Adhemerval Zanella wrote: > > > > On 19/07/2019 00:06, Rich Felker wrote: > > On Thu, Jul 18, 2019 at 05:31:51PM -0300, Adhemerval Zanella wrote: > >> > >> > >> On 18/07/2019 16:13, Florian Weimer wrote: > >>> * Adhemerval Zanella: > >>> > >>>> 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)? > >>> > >>> Does this mean that some developers see a glibc 2.31 with a 32-bit > >>> time_t on i386, and others see a 64-bit time_t? > >>> > >>>> It will move all time32 support as compat symbols for the required ABI, > >>>> without an option to select it through a build flag. Newer ports will > >>>> just have the expected symbol names, no tinkering needed. > >>> > >>> But if we build glibc with pre-5.1 kernel headers, you will get the > >>> legacy interface? > >> > >> My idea is to setup based on --enable-kernel and add a new EI_ABIVERSION > >> when time64 is used. So, depending on how glibc is built, developers > >> will indeed see a different time_t. > >> > >> Legacy builds won't build any time64 support, even with newer kernels. > >> Build set with --enable-kernel will automatically set time_t as time64 > >> and redirect the required interfaces to the new symbols ones (similar > >> to LFS, but transparently as _FILE_OFFSET_BITS=64 as being set as default). > >> > >> Newer 32-bit ports won't require anything like this as expected. > >> > >> I still think that in long term this initial bump transition is better > >> than to the complexity from mixed support. > > > > I see no reason for it to depend on the minimum kernel version glibc > > is built for. You should be able to build glibc that runs on the > > oldest still-supported kernels and that uses 64-bit time_t in the > > application-facing ABI. > > > > If built with --enable-kernel new enough, the fallback code to use old > > syscalls when the time64 ones fail with ENOSYS can be omitted. If not, > > the time64 syscalls are tried first, and if they fail, the old > > syscalls are used and the results converted. > > > > This is what musl has always planned to do regardless of whether we go > > with a hard ABI break or symbol redirection. "Only works on > > bleeding-edge kernels" is a sure way to make sure nobody uses the new > > thing, resulting in continued production of legacy binaries that are > > ticking timebombs far into the future, and all the exploding popcorn > > when 2038 approaches... > > I am aiming for make the required changes less complex and allow the > distributions to have a way to actually set or not whether to support > time64, since you can still build glibc aiming for default minimum > (3.2) while still providing a time64 enabled kernel. I personally prefer > to just make the switch based on release rather than a configure option. > > And I do agree with you that it is feasible to just make the switch > on glibc 2.31 for all 32-bit architectures and move on. However > we will need to take care of glibc some conventions, so instead of just > > -- > #if __LINUX_KERNEL_VERSION >= 0x050100 > # define __ASSUME_TIME64_SYSCALLS 1 > #endif > > int > syscall_name (...) > { > #ifdef __ASSUME_TIME64_SYSCALLS > return INLINE_SYSCALL_CALL (syscall64, ...); > #else > return INLINE_SYSCALL_CALL (syscall, ...); > #endif > } > --- > > We will need to have something like: > > -- > #if __LINUX_KERNEL_VERSION >= 0x050100 >= 0x050100 > # define __ASSUME_TIME64_SYSCALLS 1 > #endif > > int > syscall_name (args...) > { > #ifdef __ASSUME_TIME64_SYSCALLS > return INLINE_SYSCALL_CALL (syscall64, args...); > #else > int ret; > # ifdef __NR_syscall64 > static int syscall_name_supported = 1; > if (atomic_read_relaxed (&syscall_name_supported) == 1) > { > ret = INLINE_SYSCALL_CALL (syscall64, args...); > if (ret == 0 || errno != ENOSYS) > return ret; > > atomic_store_relaxed (&syscall_name_supported, 0) > } > # endif /* __NR_syscall64 */ > > ret = INLINE_SYSCALL_CALL (syscall, args...); > if (ret == 0) > ret = convert_syscall_time_to_time64 (args, ...); > return ret; > #endif > } > -- Great! This was my understanding as well (although not every patch in the latest RV32 RFC does this, that is an oversight). > > For the syscall implementation. We will have some more complexity to handle > vDSO, but it should be simplified with my refactor. Also good news! Alistair