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.8 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 D7E471F4B4 for ; Tue, 13 Oct 2020 22:18:06 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B8449386F820; Tue, 13 Oct 2020 22:18:05 +0000 (GMT) Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id A27F3385042A for ; Tue, 13 Oct 2020 22:18:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A27F3385042A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: 7Pda1rBSkw4aWDN2Gby49mjwLr1jFitxI9Gx+6ntJMGoaJSQI0fgndDgN7SYns9qCEoy+rlbA3 RJRGlwsLf1ZDMQDXLImPAdvlS2Xy9648WRppNc1q38mgAaMpWEu0mUYz98/5ovA0h9/UTdTInD J97UAOU3OOQpxeCbVwlSfOQz16HGdiQ32i9mO+p1dZdf0UPOxmsaHldtSgyq3FS7LOQ+yZU3ke Ew9AYeQo46rPICwVFmcAFqOIlywZerU+HIWvW+ag+NFaDVWInGChoaMD15PIk31bGESRca7o8S mac= X-IronPort-AV: E=Sophos;i="5.77,372,1596528000"; d="scan'208";a="53953529" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 13 Oct 2020 14:18:01 -0800 IronPort-SDR: vBMJqdpGFLsoCQYhXnRPLFREEnUuSdURJDbSTCtO2s4yOjAqkSANawEgUTwyISl5ngIb6WWNLl yC18zsdTUc2WfmcsvgIK0GuDR8vfJn3+InAp6RqYDLEnfvaN/1QFzAUst6FngLlNi9JTbO9NPh aJxKZzZe9qbnJNRU29w2lrEipYfiDQOcKcH+Kq+H6D1F98IiVFtaDIXvM7PvcSziqRkNHPKiFG SyI+lU+rWT7LQh40QZTpMTHC6If1jDCjB+JY8ufaJjoKqSZqkIhljtS9hxUMtorABFekCmouDN 1qE= Date: Tue, 13 Oct 2020 22:17:55 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Lukasz Majewski Subject: Re: [PATCH 1/2] y2038: Adjust struct __stat64_t64 to be usable by redirected {f}stat{at} calls In-Reply-To: <20201013131603.12557-1-lukma@denx.de> Message-ID: References: <20201013131603.12557-1-lukma@denx.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-02.mgc.mentorg.com (139.181.222.2) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) 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" On Tue, 13 Oct 2020, Lukasz Majewski wrote: > When glibc port with __WORDSIZE==32 and __TIMESIZE!=64 (e.g. armv7) will > use redirected calls to {f}stat{at}64_time64 functions, it will accept > the struct __stat64_t64 as its argument. > > 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. When redirecting to those functions, the definitions of struct stat / struct stat64 should automatically change as a result of the _TIME_BITS=64 definition so that they match the definitions of the __stat64_t64 type - just as _FILE_OFFSET_BITS=64 results in changes to the content of struct stat. 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. Note that struct_stat_time64.h is currently an *uninstalled* header, 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. Maybe there should be some indirection so that the installed version of struct_stat_time64.h defines a macro with all the contents of __stat64_t64, so that all the many architecture-specific bits/struct_stat.h headers can just use that macro to get the right contents when _TIME_BITS=64 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. -- Joseph S. Myers joseph@codesourcery.com