[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.
- [Bug binutils/19123] New: libbfd fails to handle > 2GB elf file on 32bit architectures,
riku.voipio at iki dot fi <=