From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) by sourceware.org (Postfix) with ESMTPS id D21E43870913 for ; Wed, 14 Oct 2020 17:50:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D21E43870913 Received: by mail-qt1-x843.google.com with SMTP id c5so2819120qtw.3 for ; Wed, 14 Oct 2020 10:50:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:autocrypt:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=X036jmVkMYFfxzMafSPthvCHPD+VcwsZey3lN6rW6tk=; b=JgmP56+8wvOM5z/o01PoH2krygbOPQJLJtN5joa6bMb1mAPhLiT2x48guxcwXaEhGm RtZDP8Ktpm3zvzO1BrGSzO+sXr0JoabTZIrqCM3IbjXPULOHI0/4dg/ThIRA6Yb/0ZN3 O+QiXVNdjgNleAJJFERZODGtMRmGjHMrTS57P///JMlK2lfeJmRvM7aq/Nab2oZUQz4b 4UbUnsbd+urku1I5Y+9eRr5QBjNqO8XDfjWTWCjziYC8q8gc+KO5X1m+zv6h6CMols8A UoNl44lJk3l0zfZMNBpoVpi7VTf5VRFHtitFj3TlMIgKaMNLdoaNmNNsxMWyHeKc5Rvg 3w4A== X-Gm-Message-State: AOAM532hD5peIJ9AHk4Ci9rijG9SWwCp8LK2gOD8bQxAORwoh0TnjHKF QiRyTdIQ1ZfMuh40ncOe3DHYvX82s4+v9w== X-Google-Smtp-Source: ABdhPJySi79KsbVbswezS+bQtFLcgc6LTWaQzHDXWlf28UMAr4W9qWRnNbL8pUgVWT1g/7Lg+G4/+A== X-Received: by 2002:ac8:33d3:: with SMTP id d19mr328144qtb.302.1602697849164; Wed, 14 Oct 2020 10:50:49 -0700 (PDT) Received: from [192.168.1.4] ([177.194.48.209]) by smtp.googlemail.com with ESMTPSA id m18sm148533qkk.102.2020.10.14.10.50.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 14 Oct 2020 10:50:48 -0700 (PDT) To: Lukasz Majewski Cc: Joseph Myers , Paul Eggert , Alistair Francis , Arnd Bergmann , Alistair Francis , GNU C Library , Florian Weimer , Carlos O'Donell , Stepan Golosunov , Andreas Schwab , Zack Weinberg References: <20201014130051.9960-1-lukma@denx.de> <3bd2f455-a49c-2230-d06b-d67c3c341910@linaro.org> <20201014161428.76862be4@jawa> <0733452c-4b8e-d3bf-f522-624dc0e2dc94@linaro.org> <20201014175629.78a42351@jawa> From: Adhemerval Zanella Autocrypt: addr=adhemerval.zanella@linaro.org; prefer-encrypt=mutual; keydata= mQINBFcVGkoBEADiQU2x/cBBmAVf5C2d1xgz6zCnlCefbqaflUBw4hB/bEME40QsrVzWZ5Nq 8kxkEczZzAOKkkvv4pRVLlLn/zDtFXhlcvQRJ3yFMGqzBjofucOrmdYkOGo0uCaoJKPT186L NWp53SACXguFJpnw4ODI64ziInzXQs/rUJqrFoVIlrPDmNv/LUv1OVPKz20ETjgfpg8MNwG6 iMizMefCl+RbtXbIEZ3TE/IaDT/jcOirjv96lBKrc/pAL0h/O71Kwbbp43fimW80GhjiaN2y WGByepnkAVP7FyNarhdDpJhoDmUk9yfwNuIuESaCQtfd3vgKKuo6grcKZ8bHy7IXX1XJj2X/ BgRVhVgMHAnDPFIkXtP+SiarkUaLjGzCz7XkUn4XAGDskBNfbizFqYUQCaL2FdbW3DeZqNIa nSzKAZK7Dm9+0VVSRZXP89w71Y7JUV56xL/PlOE+YKKFdEw+gQjQi0e+DZILAtFjJLoCrkEX w4LluMhYX/X8XP6/C3xW0yOZhvHYyn72sV4yJ1uyc/qz3OY32CRy+bwPzAMAkhdwcORA3JPb kPTlimhQqVgvca8m+MQ/JFZ6D+K7QPyvEv7bQ7M+IzFmTkOCwCJ3xqOD6GjX3aphk8Sr0dq3 4Awlf5xFDAG8dn8Uuutb7naGBd/fEv6t8dfkNyzj6yvc4jpVxwARAQABtElBZGhlbWVydmFs IFphbmVsbGEgTmV0dG8gKExpbmFybyBWUE4gS2V5KSA8YWRoZW1lcnZhbC56YW5lbGxhQGxp bmFyby5vcmc+iQI3BBMBCAAhBQJXFRpKAhsDBQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAAoJ EKqx7BSnlIjv0e8P/1YOYoNkvJ+AJcNUaM5a2SA9oAKjSJ/M/EN4Id5Ow41ZJS4lUA0apSXW NjQg3VeVc2RiHab2LIB4MxdJhaWTuzfLkYnBeoy4u6njYcaoSwf3g9dSsvsl3mhtuzm6aXFH /Qsauav77enJh99tI4T+58rp0EuLhDsQbnBic/ukYNv7sQV8dy9KxA54yLnYUFqH6pfH8Lly sTVAMyi5Fg5O5/hVV+Z0Kpr+ZocC1YFJkTsNLAW5EIYSP9ftniqaVsim7MNmodv/zqK0IyDB GLLH1kjhvb5+6ySGlWbMTomt/or/uvMgulz0bRS+LUyOmlfXDdT+t38VPKBBVwFMarNuREU2 69M3a3jdTfScboDd2ck1u7l+QbaGoHZQ8ZNUrzgObltjohiIsazqkgYDQzXIMrD9H19E+8fw kCNUlXxjEgH/Kg8DlpoYJXSJCX0fjMWfXywL6ZXc2xyG/hbl5hvsLNmqDpLpc1CfKcA0BkK+ k8R57fr91mTCppSwwKJYO9T+8J+o4ho/CJnK/jBy1pWKMYJPvvrpdBCWq3MfzVpXYdahRKHI ypk8m4QlRlbOXWJ3TDd/SKNfSSrWgwRSg7XCjSlR7PNzNFXTULLB34sZhjrN6Q8NQZsZnMNs TX8nlGOVrKolnQPjKCLwCyu8PhllU8OwbSMKskcD1PSkG6h3r0AquQINBFcVGkoBEACgAdbR Ck+fsfOVwT8zowMiL3l9a2DP3Eeak23ifdZG+8Avb/SImpv0UMSbRfnw/N81IWwlbjkjbGTu oT37iZHLRwYUFmA8fZX0wNDNKQUUTjN6XalJmvhdz9l71H3WnE0wneEM5ahu5V1L1utUWTyh VUwzX1lwJeV3vyrNgI1kYOaeuNVvq7npNR6t6XxEpqPsNc6O77I12XELic2+36YibyqlTJIQ V1SZEbIy26AbC2zH9WqaKyGyQnr/IPbTJ2Lv0dM3RaXoVf+CeK7gB2B+w1hZummD21c1Laua +VIMPCUQ+EM8W9EtX+0iJXxI+wsztLT6vltQcm+5Q7tY+HFUucizJkAOAz98YFucwKefbkTp eKvCfCwiM1bGatZEFFKIlvJ2QNMQNiUrqJBlW9nZp/k7pbG3oStOjvawD9ZbP9e0fnlWJIsj 6c7pX354Yi7kxIk/6gREidHLLqEb/otuwt1aoMPg97iUgDV5mlNef77lWE8vxmlY0FBWIXuZ yv0XYxf1WF6dRizwFFbxvUZzIJp3spAao7jLsQj1DbD2s5+S1BW09A0mI/1DjB6EhNN+4bDB SJCOv/ReK3tFJXuj/HbyDrOdoMt8aIFbe7YFLEExHpSk+HgN05Lg5TyTro8oW7TSMTk+8a5M kzaH4UGXTTBDP/g5cfL3RFPl79ubXwARAQABiQIfBBgBCAAJBQJXFRpKAhsMAAoJEKqx7BSn lIjvI/8P/jg0jl4Tbvg3B5kT6PxJOXHYu9OoyaHLcay6Cd+ZrOd1VQQCbOcgLFbf4Yr+rE9l mYsY67AUgq2QKmVVbn9pjvGsEaz8UmfDnz5epUhDxC6yRRvY4hreMXZhPZ1pbMa6A0a/WOSt AgFj5V6Z4dXGTM/lNManr0HjXxbUYv2WfbNt3/07Db9T+GZkpUotC6iknsTA4rJi6u2ls0W9 1UIvW4o01vb4nZRCj4rni0g6eWoQCGoVDk/xFfy7ZliR5B+3Z3EWRJcQskip/QAHjbLa3pml xAZ484fVxgeESOoaeC9TiBIp0NfH8akWOI0HpBCiBD5xaCTvR7ujUWMvhsX2n881r/hNlR9g fcE6q00qHSPAEgGr1bnFv74/1vbKtjeXLCcRKk3Ulw0bY1OoDxWQr86T2fZGJ/HIZuVVBf3+ gaYJF92GXFynHnea14nFFuFgOni0Mi1zDxYH/8yGGBXvo14KWd8JOW0NJPaCDFJkdS5hu0VY 7vJwKcyHJGxsCLU+Et0mryX8qZwqibJIzu7kUJQdQDljbRPDFd/xmGUFCQiQAncSilYOcxNU EMVCXPAQTteqkvA+gNqSaK1NM9tY0eQ4iJpo+aoX8HAcn4sZzt2pfUB9vQMTBJ2d4+m/qO6+ cFTAceXmIoFsN8+gFN3i8Is3u12u8xGudcBPvpoy4OoG Subject: Re: [PATCH] y2038: Reorder placement of st_ino in struct __stat64_t64 Message-ID: Date: Wed, 14 Oct 2020 14:50:44 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201014175629.78a42351@jawa> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Wed, 14 Oct 2020 17:50:51 -0000 On 14/10/2020 12:56, Lukasz Majewski wrote: > Hi Adhemerval, > >> On 14/10/2020 11:14, Lukasz Majewski wrote: >>> Hi Adhemerval, >>> >>>> On 14/10/2020 10:00, Lukasz Majewski wrote: >>>>> In the installed struct stat{64} the __ino64_t st_ino member is >>>>> placed in the end. This patch moves it to the same position as in >>>>> the aforementioned, exported structures as it allows less #ifdefs >>>>> for __USE_TIME_BITS64 support use case. >>>> >>>> Why exactly this is required? Afaik this is glibc defined type not >>>> currently only used internally and all member accesses are set >>>> directly (no use or memcpy or offsetof). Is this related to the >>>> issue you saw on the arm environment? >>> >>> This is required to make the minimal changes to provide >>> -D_TIME_SIZE=64 support for {f}stat{at} as in: >>> https://github.com/lmajewski/y2038_glibc/commit/26aa2ac07246682a505d85dac1c269689964b79b >>> >> >> But the idea it to decouple y2038 stat from the generic stat which >> support non-LFS and make it support solely LFS. > > And this idea is correct. > >> As Joseph has pointed >> out, the __stat64_t64 should be architecture-independent and I think >> it simplifies its definition to untie from struct_stat.h (which >> has multiple definitions due historically each architecture >> to tie with the selected kernel ABI). > > This is also correct assumption. > > Please find my explanation of the problem as I may not been correctly > understood: > > For example the __fstat64_time64 defined in > sysdeps/unix/sysv/linux/fstat64.c has following signature: > > int __fstat64_time64 (int fd, struct __stat64_t64 *buf) > > for: > - __WORDSIZE==64 is struct __stat64_t64 is aliased to struct stat64, Not __WORDSIZE==64 but rather XSTAT_IS_XSTAT64, since mips64 and mips64-n32 provides non-LFS interfaces. For XSTAT_IS_XSTAT64 ABIs, __stat64_t64 is also essentially stat and the {f,l}stat{at}64 is aliased to {f,l}stat{at}. > - __WORDSIZE==32 (Non Y2038) uses __fstat64 with struct stat64 > - __WORDSIZE==32 (Y2038) will redirect fstat calls to __fstat64_time64 > and as a result it will have to accept *buf which must be binary > compatible with struct stat{64} and __stat64_t64. Yes, fstat on __WORDSIZE==32 with XSTAT_IS_XSTAT64 will be an alias to __fstat64_time64 (and this now assumed that any new 32-bit ABI will have to only provide LFS interfaces and 64-bit time_t). Also for such cases __stat64_t64 *won't* be exported, its struct stat *already* has 64-bit time fields. > > By binary compatible I mean the layout and fields must be identical as > passing struct stat{64} to __fstat64_time64 will force casting of the > data pointed by *buf. I think there is a confusion here, for currently y2038 enabled ABIs you will have either the first situation or the second you described. For future y2038 ABIs (basically all 32-bit that still supports 32-bit time_t) __stat64_t64 and stat64 do *not* require to be binary compatible. In this case you will have: 1. non-LFS {f,l}stat{64} that accepts 'struct stat'. 2. LFS with 32-bit time fields {f,l}stat{64} that accepts 'struct stat64'. 3. LFS with 64-bit time fields {f,l}fstat64_t64 (or any other name for the exported ABI) with accepts 'struct __stat64_t64'. This is *different* than the current 32-bit y2038 enabled ABIs (arc, riscv32) which does not need to support neither 1. nor 2.. For this architecture the exported ABI is similar to current majority 64-bit architectures (modules mips64...), where they exports {f,l}stat{at} with {f,l}stat{at}{64} being just aliases. So for instance on ARM, to actually use the y2038 calls we will need to export the __{f,l}stat{at}64_time64 along with the 'struct __stat64_t64' *and* redirects the LFS calls {f,l}stat{at}64 calls to _{f,l}stat{at}64_time64 for _TIME_BITS=64 (along with redefine the 'struct stat64' to 'struct __stat64_t64'). > > With current situation we do have > (at sysdeps/unix/sysv/linux/struct_stat_time64.h): > > struct __stat64_t64 > { > __dev_t st_dev; > __ino64_t st_ino; > > > Which is placed just after st_dev. > > In the struct stat{64} the st_ino is the last member. > > As a result we do have a mismatch when passing binary data (the offsets > are different for st_ino). > > Code from this patch moves st_ino to the last place, which saves a lot > of extra code - i.e. one for alleviating the casting of data. > > Due to that also the patch in > https://github.com/lmajewski/y2038_glibc/commit/26aa2ac07246682a505d85dac1c269689964b79b > > can be small. > > >> >> It leads to define the struct __stat64_t64 on its own header instead >> of trying to accommodate it on stat.h header. The idea it to >> eventually export struct_stat_time64.h as an installed header and >> make the required redirections on stat.h header for -D_TIME_SIZE=64 >> (so stat64 redirects to __stat_time64). > > As it is now - those two structures are not binary compatible due to > different st_ino placement (of course if we _only_ copy data with direct > assignment, then we are safe). > > > Best regards, > > Lukasz Majewski > > -- > > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de >