bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/19123] New: libbfd fails to handle > 2GB elf file on 32bit


From: riku.voipio at iki dot fi
Subject: [Bug binutils/19123] New: libbfd fails to handle > 2GB elf file on 32bit architectures
Date: Tue, 13 Oct 2015 13:40:02 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=19123

            Bug ID: 19123
           Summary: libbfd fails to handle > 2GB elf file on 32bit
                    architectures
           Product: binutils
           Version: 2.25
            Status: NEW
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: riku.voipio at iki dot fi
  Target Milestone: ---

Created attachment 8708
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8708&action=edit
use file_ptr for seek position in elf files

Build of chrome fails on arm-linux-gnueabi plaftorm with error from strip:

strip:debian/chromium/usr/lib/chromium/chromium: File truncated

objcopy, objdump etc all fail same way. This is because the binary is over 2GB
and libbfd uses a signed 32bit variable for passing seek locations:

bfd_signed_vma where = i_ehdrp->e_shoff;

The minimal fix is s/bfd_signed_vma/bfd_vma/ but considering "where" is only
ever used as input for bfd_seek, and bfd_seek is defined as:

bfd_seek (bfd *abfd, file_ptr position, int direction)

Using file_ptr directly saves from some casts and makes some checks pointless.
Attached patch that fixes that does it, and fixes chrome build for me. objdump,
strip and objcopy handle the +2GB binary now fine. 

Patch is against 2.25.1 from Debian

-- 
You are receiving this mail because:
You are on the CC list for the bug.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]