From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 8DC293858403 for ; Wed, 13 Oct 2021 20:47:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8DC293858403 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: DUcIPQRHUtxGGJGvW8tAue5wL49MfQBWqRA1xkeofL7a0NBj/7PNdtjLm8VDFKU7wfuHl5PK1i xwbid2rDpIUSanZgyPBtVyVlcEc+QeL1mxiwcoD1WmnJ4MvrYi2805OriG8pdmbXsZot92SpM5 W7KjlqrfvHK4HX5KaFkcCvhOUR4er+fvWPYK0CEhfsN1GwlDPAzY2+3OdKeXQaq7jF8pdq8QcB v6nCb/tYc/LTR44lI1l7CcGGH9gEYg6J4zfgo+PBBVq69ylmRIgb5vCpJYly3p0KVxX5S+uVVr B2gZwPT0feZevsncOkTJpPvm X-IronPort-AV: E=Sophos;i="5.85,371,1624348800"; d="scan'208";a="67178422" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 13 Oct 2021 12:47:44 -0800 IronPort-SDR: m9NJW3CbZE1vveYXea9Vp434H2ZBE5xwFYZXysl3HKUpwCIzAA+FqbCCtx+LG5A6MgijTQyaRq Zz4EYurB6stG4L5hAzbrO7MViKSRk5WnMeL0LGQGRLt1rHnbiktMjZre0zUfp+hlO2PZX1nqGh qp6mhDA4dEolil80D0t8vFcuUk1i6JrfB9INKOgQHVYKRHwFoLcRRin//o88H02mVTX4vAOtDv teyITERCwhkGv9mjZGw8rPc8rrS1CBX4Asth0Swz1YgwZrxbWFnN4MgBzcHtpIYgqukrVqDdQI jy4= Date: Wed, 13 Oct 2021 20:47:39 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Stafford Horne CC: Adhemerval Zanella , GLIBC patches Subject: Re: [PATCH v3 18/24] y2038: Add support for 64-bit time on legacy ABIs In-Reply-To: Message-ID: References: <20210607203613.282543-1-adhemerval.zanella@linaro.org> <20210607203613.282543-19-adhemerval.zanella@linaro.org> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3117.6 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 13 Oct 2021 20:47:47 -0000 On Wed, 13 Oct 2021, Stafford Horne via Libc-alpha wrote: > Now, I am trying to build with > CFLAGS="-g -Og -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64", > but this is causing build failures. glibc can't be built with those options. All the setup for building functions with the correct names and aliases assumes that those macros are not defined when building glibc itself; defining them will cause function redirections that are only appropriate for user applications, not for building glibc itself. > > +@item > > +@code{_TIME_BITS=64} and port from the outset uses 64-bit > > +@code{time_t} and word size equals to @w{32 bits} (e.g. ARC, RV32) > > +- no action > > OpenRISC falls into this category. We have 64-bit support but word size is > 32 bits. > > What does "no action" mean here? Does it mean as long as I set _TIME_BITS=64 > no extra porting effort is needed? "no action" means _TIME_BITS does nothing and the user gets 64-bit time regardless. As with any port, the architecture-specific files need to be set up appropriately for the choices made by the port, and new ports may sometimes encounter issues in architecture-independent files for ports not needing various kinds of compatibility. > Is this correct? We only use __USE_TIME_BITS64 on machines where > __TIMESIZE==32? The purpose of __USE_TIME_BITS64 is to enable header redirections to different function names on systems that support both 32-bit and 64-bit time_t. For an architecture that only supports 64-bit time_t, no such redirections should ever be in effect and no separate function names for 64-bit time_t should exist, so __USE_TIME_BITS64 should not be defined. OpenRISC should be just like x86_64 in this regard. -- Joseph S. Myers joseph@codesourcery.com