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-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id B84591F4B4 for ; Tue, 13 Oct 2020 14:24:29 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A6B253894422; Tue, 13 Oct 2020 14:24:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A6B253894422 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1602599068; bh=DywPaJ8Axh1bzwIqQcXGhWGfuKU6CQYWZJ3hvi/TDr8=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=TEXknocSCgPijFb1wgNVtxn78Obo5qJzgK7Vz64m4ZdT7Rk38n/24alePoxUL1NGi 7o77DXaSFC+vUwPZOcuF979KluXUGb32KRLU++o8CXxtPoZGR70y0lm4/zyd4fgqiM EWw0kn0JgdFD7ywyaBHsEgz8oNrBxUPH6R2HGaFA= Received: from mail-oi1-x242.google.com (mail-oi1-x242.google.com [IPv6:2607:f8b0:4864:20::242]) by sourceware.org (Postfix) with ESMTPS id 15C913894422 for ; Tue, 13 Oct 2020 14:24:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 15C913894422 Received: by mail-oi1-x242.google.com with SMTP id s81so10267833oie.13 for ; Tue, 13 Oct 2020 07:24:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DywPaJ8Axh1bzwIqQcXGhWGfuKU6CQYWZJ3hvi/TDr8=; b=im/aDul5Acp23w4Ngske2T2Tr5LV9nT/0MEIhi/92GhrQdcZ2wT/wPqaeOe4L/YHSW zjZxSuS/MHqoa1bvMxlJCi+J8f4CsR5ehghi8KfPrZw2TDOLPiWolfxSBI+qpG5atgak DunV6XDR+HuFZGFUM9Dn57CkmZeO+paHThRZ1TTaPz9dLyCKWtlphxbMbpSlWgMTXpuE SmOSaqvnx0/UYBldc4Q5taauXLq35VAmzsnmi3vPWrxvd9U3fCoLGc9cffZmIOPREvYh kMlqn/nqYQCG5Qi6vfeiNylR5cztG3hTVOB4w4JSeiZ3s3OgIV2NDgJkpNuEGRHXZBAS DF5g== X-Gm-Message-State: AOAM530XXi/fj8TQw1hFKajEMFrCr2sBUosFNhGlf8OiAhw0LX2ombd8 vVaOhUTxvX1fLvtRjmU9o54+6gLlzqt6Bz/XIBQ= X-Google-Smtp-Source: ABdhPJwj7jrDgujhmhYpDikRZeUWanxiIy/QGJu+J+sjU9In6y+1mAkJDwkUNkdoK3+O9uHvU45xsQPHL/ohi27/fdk= X-Received: by 2002:aca:5058:: with SMTP id e85mr105715oib.79.1602599064458; Tue, 13 Oct 2020 07:24:24 -0700 (PDT) MIME-Version: 1.0 References: <20200723194641.1949404-1-adhemerval.zanella@linaro.org> <20200723194641.1949404-16-adhemerval.zanella@linaro.org> <20201006114802.1450d29b@jawa> <99a35800-d0ed-5561-b36b-4416f041ab5d@linaro.org> <331ab260-ef82-8e94-7148-5522fdb6e195@linaro.org> <20201013155838.0e61252b@jawa> <250a2b16-f06a-7215-bb8a-445511a4976f@linaro.org> In-Reply-To: <250a2b16-f06a-7215-bb8a-445511a4976f@linaro.org> Date: Tue, 13 Oct 2020 07:23:48 -0700 Message-ID: Subject: Re: [PATCH 15/16] linux: Add {f}stat{at} y2038 support To: Adhemerval Zanella Content-Type: text/plain; charset="UTF-8" X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" Cc: GNU C Library , Alistair Francis Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Tue, Oct 13, 2020 at 7:18 AM Adhemerval Zanella via Libc-alpha wrote: > > > > On 13/10/2020 10:58, Lukasz Majewski wrote: > > Hi Adhemerval, > > > >> On 07/10/2020 09:52, Adhemerval Zanella wrote: > >>> > >>> > >>> On 06/10/2020 06:48, Lukasz Majewski wrote: > >>>> Hi Adhemerval, > >>>> > >>>>> A new struct __stat{64}_t64 type is added with the required > >>>>> __timespec64 time definition. Both non-LFS and LFS support were > >>>>> done with an extra __NR_statx call plus a conversion to the new > >>>>> __stat{64}_t64 type. The statx call is done only for > >>>>> architectures with support for 32-bit time_t ABI. > >>>>> > >>>>> Internally some extra routines to copy from/to struct stat{64} > >>>>> to struct __stat{64} used on multiple implementations (stat, > >>>>> fstat, lstat, and fstatat) are added on a extra file > >>>>> (stat_t64_cp.c). Aslo some extra routines to copy from statx to > >>>>> __stat{64} is added on statx_cp.c. > >>>>> > >>>>> Checked with a build for all affected ABIs. I also checked on > >>>>> x86_64, i686, powerpc, powerpc64le, sparcv9, sparc64, s390, and > >>>>> s390x. > >>>> > >>>> When do you plan to pull this patch set to -master? > >>>> Those patches have been available for review on the mailing list > >>>> for more than two months now. > >>> > >>> Hi Lukasz, thanks to remind me. I will rebase against master and run > >>> some regressions tests against some platforms and push it. > >>> > >> > >> One required change with the rebase is adapt the riscv32 ABI to > >> exclude the __{f,l}xstat{at} symbol and replace with proper {f,l}stat > >> ones. It is possible because the new ABI was added on current > >> development branch, however one minor inconvenient is the toolchain > >> need to be rebuild with a updated glibc branch to avoid linking > >> failures with libstd++ (which uses __{f,l}xstat{at}). > >> > > > > I'm not sure if this is related, but on my ARMv7 (32 bit) sandbox there > > is an issue with fstat accesses to files. > > > > When I try to run a program build against newest glibc (installed in > > /opt/lib) I do see issues with {f}stat on other libraries (e.g. > > /opt/lib/librt.so). To be more specific I do experience the EOVERFLOW > > error: > > > > error while loading shared libraries: librt.so.1: cannot stat shared > > object: Error 75 > > > > The "base" glibc is 2.28 (installed in /lib). The glibc under test is > > the newest master installed in /opt/lib. > > > > I'm now investigating this issue. > > I am not sure what it might be based on these information, could you > provide a strace so we can pinpoint what might the issue? > > The arm-linux-gnueabihf testing I did was on a aarch64 kernel (4.12.13). > Besides the make check without regression, I could run system binaries > with ./testrun.sh. > > I will check on a different kernel/system with a 32-bit kernel. FWIW, I got FAIL: glibcs-armeb-linux-gnueabi-be8 check FAIL: glibcs-armeb-linux-gnueabi check FAIL: glibcs-armeb-linux-gnueabihf-be8 check FAIL: glibcs-armeb-linux-gnueabihf check FAIL: glibcs-m68k-linux-gnu-coldfire check FAIL: glibcs-m68k-linux-gnu-coldfire-soft check FAIL: glibcs-microblazeel-linux-gnu check FAIL: glibcs-mipsel-linux-gnu-nan2008-soft check FAIL: glibcs-mipsel-linux-gnu-soft check FAIL: glibcs-mips-linux-gnu-nan2008-soft check FAIL: glibcs-mips-linux-gnu-soft check FAIL: glibcs-powerpc-linux-gnu-soft check FAIL: glibcs-riscv32-linux-gnu-rv32imac-ilp32 build FAIL: glibcs-riscv32-linux-gnu-rv32imafdc-ilp32 build FAIL: glibcs-riscv32-linux-gnu-rv32imafdc-ilp32d build FAIL: glibcs-sh3eb-linux-gnu check FAIL: glibcs-sh4eb-linux-gnu check FAIL: glibcs-sh4eb-linux-gnu-soft check UNRESOLVED: glibcs-riscv32-linux-gnu-rv32imac-ilp32 check UNRESOLVED: glibcs-riscv32-linux-gnu-rv32imac-ilp32 install UNRESOLVED: glibcs-riscv32-linux-gnu-rv32imac-ilp32 mkdir-lib UNRESOLVED: glibcs-riscv32-linux-gnu-rv32imafdc-ilp32 check UNRESOLVED: glibcs-riscv32-linux-gnu-rv32imafdc-ilp32d check UNRESOLVED: glibcs-riscv32-linux-gnu-rv32imafdc-ilp32d install UNRESOLVED: glibcs-riscv32-linux-gnu-rv32imafdc-ilp32d mkdir-lib UNRESOLVED: glibcs-riscv32-linux-gnu-rv32imafdc-ilp32 install UNRESOLVED: glibcs-riscv32-linux-gnu-rv32imafdc-ilp32 mkdir-lib -- H.J.