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=-3.7 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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 B696A1F4B4 for ; Wed, 14 Oct 2020 08:48:35 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 687083854827; Wed, 14 Oct 2020 08:48:33 +0000 (GMT) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.10]) by sourceware.org (Postfix) with ESMTPS id 148393854822 for ; Wed, 14 Oct 2020 08:48:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 148393854822 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: sourceware.org; spf=none smtp.mailfrom=lukma@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 4CB5fg3SNGz1rvyK; Wed, 14 Oct 2020 10:48:27 +0200 (CEST) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 4CB5fg0q6wz1qryc; Wed, 14 Oct 2020 10:48:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id CWIe6HFEIZRr; Wed, 14 Oct 2020 10:48:25 +0200 (CEST) X-Auth-Info: /Inx6fp2by5z4ARWJDBDNJT6/v3hnxFRpWwJqlX/D70= Received: from jawa (85-222-111-42.dynamic.chello.pl [85.222.111.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Wed, 14 Oct 2020 10:48:25 +0200 (CEST) Date: Wed, 14 Oct 2020 10:47:50 +0200 From: Lukasz Majewski To: Joseph Myers Subject: Re: [PATCH 1/2] y2038: Adjust struct __stat64_t64 to be usable by redirected {f}stat{at} calls Message-ID: <20201014104750.230023bc@jawa> In-Reply-To: References: <20201013131603.12557-1-lukma@denx.de> Organization: denx.de X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/lFFpybwk8Iw08z3fdNa11L4"; protocol="application/pgp-signature" 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: , Cc: Florian Weimer , GNU C Library , Andreas Schwab , Stepan Golosunov , Alistair Francis Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" --Sig_/lFFpybwk8Iw08z3fdNa11L4 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Joseph, > On Tue, 13 Oct 2020, Lukasz Majewski wrote: >=20 > > When glibc port with __WORDSIZE=3D=3D32 and __TIMESIZE!=3D64 (e.g. armv= 7) > > will use redirected calls to {f}stat{at}64_time64 functions, it > > will accept the struct __stat64_t64 as its argument. > >=20 > > To avoid errors related to proper data placement after casting from > > struct __stat64_t64 to struct stat{64} it is necessary to add some > > missing padding and update type of {__}st_ino member. =20 >=20 > When redirecting to those functions, the definitions of struct stat /=20 > struct stat64 should automatically change as a result of the > _TIME_BITS=3D64 definition so that they match the definitions of the > __stat64_t64 type - just as _FILE_OFFSET_BITS=3D64 results in changes > to the content of struct stat. Thanks for the explanation. I will adjust exported struct stat{64] accordingly. >=20 > I believe the design is that __stat64_t64 has an > architecture-independent layout that is never required to match any > particular kernel layout because translation (typically from statx) > will always occur in userspace. >=20 > Note that struct_stat_time64.h is currently an *uninstalled* header,=20 > despite the name of the multiple-include guard in the header, and > despite the testing of feature test macros within the header (which > only makes sense for installed headers); it's not a bits/ header at > present. The only change, that I'm going to do is to mode __ino64_t st_ino member of struct __stat64_t64 (@ sysdeps/unix/sysv/linux/struct_stat_time64.h) to the end of this structure (as it is in the exported struct stat{64} placed). This would allow less #ifndef __USE_TIME_BITS64 in the exported struct stat{64}. >=20 > Maybe there should be some indirection so that the installed version > of struct_stat_time64.h defines a macro with all the contents of=20 > __stat64_t64, so that all the many architecture-specific=20 > bits/struct_stat.h headers can just use that macro to get the right=20 > contents when _TIME_BITS=3D64 rather than needing to duplicate the > structure contents (at least twice per header, for both stat and > stat64). But I don't think any change to the layout of __stat64_t64 > is indicated, because there should always be explicit conversions > between different layouts. >=20 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 --Sig_/lFFpybwk8Iw08z3fdNa11L4 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAl+GuzYACgkQAR8vZIA0 zr1zFQgAkUtplMTUZ/R3zq2Fr32Wo4aAacLjKEmReOOX9IIzXpeDfkK6R9M8wqMh 6673e9q34zvJKz2GsnxtKCAYGQ7ulPA1FBrqx1DS4cS/zR4Mhc/bVTqY9G/5E8w8 S5XArl9tgkfLpQg7x637na6P0mWhwrWaXBdVyGjAFDDSfdR8FLPPmSiEgOumabHT xlI35h4yUAp3IReDozkDfHbvEFNJOHllY3pmVmzE4G/Z5pIEaUG/oQLahcohCMTt 3e4ALercb7m57YPs5Q1vAUy+rE47D10I0hiX4kSnv/f3W1iE2FHOUsS8bQVK4YLT MOOWFAjRvQ3KarLpPbHTb5WmgTRm4g== =6vOb -----END PGP SIGNATURE----- --Sig_/lFFpybwk8Iw08z3fdNa11L4--