From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id 782B4395A462 for ; Wed, 16 Nov 2022 14:02:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 782B4395A462 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Received: by smtp.gentoo.org (Postfix, from userid 559) id 5FC9C340B77; Wed, 16 Nov 2022 14:01:34 +0000 (UTC) Date: Wed, 16 Nov 2022 21:01:32 +0700 From: Mike Frysinger To: Jan Beulich Cc: Alan Modra , Brett Werling , binutils@sourceware.org Subject: Re: [PATCH] readelf: use fseeko for elf files >= 2 GiB on x86_64-mingw32 Message-ID: Mail-Followup-To: Jan Beulich , Alan Modra , Brett Werling , binutils@sourceware.org References: <20221114150348.112815-1-bwerl.dev@gmail.com> <8c1844c9-4b04-0200-c24e-c33009562477@suse.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sjDX0SMioK/9HOuP" Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_NUMSUBJECT,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --sjDX0SMioK/9HOuP Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 16 Nov 2022 11:46, Jan Beulich wrote: > On 16.11.2022 11:09, Mike Frysinger wrote: > > On 15 Nov 2022 08:12, Alan Modra via Binutils wrote: > >> On Mon, Nov 14, 2022 at 09:52:30AM -0600, Brett Werling via Binutils w= rote: > >>> On Mon, Nov 14, 2022 at 9:30 AM Jan Beulich wrote: > >>>> On 14.11.2022 16:03, Brett Werling via Binutils wrote: > >>>>> Switch all fseek calls to fseeko and cast the given offset as an of= f_t > >>>>> accordingly. When building readelf for x86_64-mingw32, a long will = only > >>>>> be 32 bits wide. If the elf file in question is >=3D 2 GiB, that is > >>>>> greater than the max long value, and therefore fseek will fail > >>>>> indicating that the offset is negative. > >>>>> > >>>>> To work around this and support up to 4 GiB, we switch to using fse= eko > >>>>> and cast the unsigned long offsets as off_t values because the size= of > >>>>> off_t is 64 bits on x86_64-mingw32. > >>>> > >>>> Is fseeko() uniformly available on all platforms binutils can be bui= lt > >>>> for? I'm afraid the answer is no, so at least you'd need to introduce > >>>> some configure logic for this plus some abstraction. > >>> > >>> I think you are correct, this will need some conditional logic to be = "safe" > >>> to > >>> include, and even then the casting to off_t would become a little more > >>> complicated. I will look deeper into what can be done here. > >> > >> See bfd/bfdio.c and bfd/configure.ac > >=20 > > should we look at bfd using gnulib ? growing our own portability layer= sounds > > like a lot of dupicative effort ... >=20 > Right now binutils can be built and run on pretty old distros. Unless a p= retty > old gnulib would be taken as the baseline, this property would be lost wi= th > the introduction of such a dependency. sounds like an issue to bring up with the gnulib folks then ? it's already a hard requirement for gdb and related. realistically, is anyone actually testing those old distros ? -mike --sjDX0SMioK/9HOuP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmN07TwACgkQQWM7n+g3 9YFTyxAAojcp8lur9mJaQ972WTaVUVmpV3McV3ATiB+azmQbGJbAWZgYBUsxxpkR vdvO5HVI/tcH9TxLJwdhf8FaTQ3Wdesnp06n//zzwZUAXSU1RsibJ0Z0PXtwg4J1 AiLmX9jQ0yfTgTEF8COCTUjvYOU2uofCZE0rUIQYMVBJJ8ZwILaRMuTHjLJ6lrmh DqjmvwigXu/XZ0Hncy7BFtJXIbPPwPhnJ5e8ayihMXy/HVk0uIk0lo6JUxCSQYc9 LBh/gAGpXOJb8KYB0+xsmgjEd+IKc0xqzQvViZ6xfYjd+dkHCK3VeljWuCcl8AUD 14GaQIeu0LwALOOoWW0GR7BNwAQXsrTZX8l7co/97OqHvO4udfgWCFqHRYxsBQAF FHxcrvxCWffXTw2uevtAf2BgvTPskdpLzpjLve4aR2nhImZctVd04r5b3tML2LC+ D3A2E5H5PPn8rq0rak02Z/R5Ao4klHzwMypJJiXMAOmUNNRJuWwccgl6P81FKyyv b5Jit7wnEKgqaMmnU51OLiSrQRHEBPbknn5RFXgODFO+BGp3v8gnE6EOpwsQoMkq 7NvTaSNTlNs8yJEanWuoN0iJFh+23c5avTPZoTrLg8mXQGS8KRmzpNPifVH/yxTh afU5GkOQM+VlAbuAFqPIesgMYUXQpNbk8tmBJREimdqCAV1sjSs= =6oYo -----END PGP SIGNATURE----- --sjDX0SMioK/9HOuP--