[PATCH] readelf: use fseeko for elf files >= 2 GiB on x86_64-mingw32

[Mike Frysinger]

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 wrote:
> >>> On Mon, Nov 14, 2022 at 9:30 AM Jan Beulich <jbeulich@suse.com> 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 off_t
> >>>>> accordingly. When building readelf for x86_64-mingw32, a long will only
> >>>>> be 32 bits wide. If the elf file in question is >= 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 fseeko
> >>>>> 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 built
> >>>> 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
> > 
> > should we look at bfd using gnulib ?  growing our own portability layer sounds
> > like a lot of dupicative effort ...
> 
> Right now binutils can be built and run on pretty old distros. Unless a pretty
> old gnulib would be taken as the baseline, this property would be lost with
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20221116/0c7a6e9d/attachment.sig>