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.8 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 C00511F462 for ; Mon, 29 Jul 2019 18:55:26 +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 :content-transfer-encoding; q=dns; s=default; b=bmrdzPjurga2t2Bj KL8+z+GonY1dLArgbVPX00RqdSbA9yqguahVQf5kduQmj0FeMW4xZij+t1QrTfmP Vdo0kGt0AFM8JKYjG9ewNKSaLA3NkEWqmlMLQsBkxp/62KLXeq1zZbi8LZ291mOT fHh1S9uKHhQ2kg5bCGGsCFLPp+A= 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 :content-transfer-encoding; s=default; bh=SxKWksb94HfCVfXO3LjKeQ zFfK8=; b=bijum7gxEe3Po7I4QuAUdzodaNi1klTdDH75hkJO3jwAmB6I0hMx+n km8MJEJuT/1e+q/2lflXBypEu1LijSloDmOqprbkb1b1psuHoSyaXBbbSCkHQIiz ACRHY0BxkXrEaHqcuudc1LjkQDnSqrLeEqWsfn+M0idzfasw4hwkU= Received: (qmail 8863 invoked by alias); 29 Jul 2019 18:55:24 -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 8855 invoked by uid 89); 29 Jul 2019 18:55:24 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mailbackend.panix.com MIME-Version: 1.0 References: <20190712072103.D3DBC24003A@gemini.denx.de> <20190726123902.6f8813da@jawa> In-Reply-To: <20190726123902.6f8813da@jawa> From: Zack Weinberg Date: Mon, 29 Jul 2019 14:55:07 -0400 Message-ID: Subject: Re: Accelerating Y2038 glibc fixes To: Lukasz Majewski Cc: Joseph Myers , Wolfgang Denk , GNU C Library , Alistair Francis , Alistair Francis Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 26, 2019 at 6:39 AM Lukasz Majewski wrote: ... > > > See for example [1] - there are just 7 lines of "code". But Joseph > > > does not accept our patches. The arguments he gives are not on a > > > technical level; ... > Our goal is to add a solid foundation for the Y2038 work, so we would > know the direction where we are heading. ... > If you think that it would be better and most of all faster if you > rewrite the description, then I don't mind. > > It would be great if you could do it sooner than latter as this slows > down our development. ... > The most recent version of this patch set (v8): > https://patchwork.ozlabs.org/patch/1117100/ I haven=E2=80=99t been following the details of these patches super careful= ly, and I=E2=80=99m not sure I understand what _Joseph=E2=80=99s_ concerns with= your writing is. However, I=E2=80=99m a native English speaker, I=E2=80=99ve re= ad over the text in the patch at , I do think I understand the issues at a high level, and I do think the meaning of __ASSUME_TIME64_SYSCALLS could be explained more clearly. I=E2=80=99m prepared to work with you to come up with better wording but I need to ask you a bunch of questions. Could you please reply to each of the queries marked Qn below? As I understand it, we have five distinct cases to consider: 1. All future LP64 ABIs and all but one existing LP64 ABI, identified by __WORDSIZE =3D=3D 64: time_t is already a 64-bit integer type and all of the relevant system calls already accept it in that form. glibc=E2=80=99s implementation of, for instance, clock_gettime may conti= nue to invoke the system call numbered __NR_clock_gettime. 2. The exception to (1) is Alpha. That is an exclusively LP64 architecture, but in glibc 2.0 it used 32-bit time_t, and we still have compatibility code for that case. The compatibility symbols invoke a set of compatibility syscalls with =E2=80=98osf=E2=80=99 in the= ir names: for instance, gettimeofday@GLIBC_2.0 invokes __NR_osf_gettimeofday. Not all of the time-related functions in glibc have compatibility symbols, only those that existed in version 2.0. Your patches do not touch this compatibility code at all, as far as I can see. Alpha being out of production, and binaries compiled against glibc 2.0 being rare anyway, it would only make sense to involve this code in your patches if it reduced the overall volume of compatibility code somehow, but regardless we need to make sure it doesn't break. 3. x32 (recently new 32-bit ABI for x86): like case 1, time_t is already 64-bit and we use unsuffixed system calls. The text says this case is identified by __WORDSIZE =3D=3D 32 && __TIMESIZE =3D=3D 64, but the code actually checks __SYSCALL_WORDSIZE. Q1: Which condition correctly identifies this case, __TIMESIZE =3D=3D 64= or __SYSCALL_WORDSIZE =3D=3D 64? Q2: Could we perhaps ensure that __TIMESIZE and/or __SYSCALL_WORDSIZE is defined to 64 whenever __WORDSIZE =3D=3D 64? Then we could collapse this into case 1. 4. Brand-new (added in kernel 5.1 or later) 32-bit ABIs: time_t will always be 64-bit, _but_ glibc=E2=80=99s implementation of time-related A= PIs may need to invoke system calls with suffixed names: clock_gettime invoking __NR_clock_gettime64, for instance. Also, the kernel will not provide all of the time-related system calls that have historically existed; glibc must, for instance, implement gettimeofday in terms of clock_gettime. Q3: What macros are defined for this case? Q4: Does glibc need to call system calls with suffixed names in this case? Q4a: If the answer to Q4 is =E2=80=98yes=E2=80=99, why is that, and can = we change the kernel so that it=E2=80=99s the same as x32 and the LP64 architectur= es? (Either by removing the suffixes, or by _adding_ suffixed aliases to asm/unistd.h for x32 and LP64 architectures.) 5. Historical 32-bit ABIs, where the existing set of system calls takes 32-bit time_t, and Linux 5.1 added a matching set that takes 64-bit time_t. For compatibility with old programs that make direct system calls, the kernel will not rename the __NR_ constants for the old (32-bit) system calls; instead new constants with =E2=80=986= 4=E2=80=99 or =E2=80=98time64=E2=80=99 suffixes will be added. As in case 4, the n= ew set of system calls does not cover all of the historic time-related system calls. In this case, and only this case, glibc=E2=80=99s code needs to account = for the possibility that the new __NR_ constants are not defined (because glibc is being compiled against kernel headers from a version older than 5.1), or that the new system calls are not available at runtime (glibc was compiled against new kernel headers but is running with an old kernel). The #if is complicated enough that I=E2=80=99m not sure, but I _think_ y= our code only defines __ASSUME_TIME64_SYSCALLS when the new constants are _guaranteed_ to be defined. Q5: Is it correct that __ASSUME_TIME64_SYSCALLS is only defined when the new constants are guaranteed to be defined? Q6: All of the other __ASSUME_ constants mean both that we assume the kernel headers are new enough to provide all the necessary declarations, and that we assume the feature is available at runtime: no fallback code will be included in the library. Is this also the intended meaning of __ASSUME_TIME64_SYSCALLS? zw