From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11440 invoked by alias); 3 Apr 2014 09:21:02 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 11425 invoked by uid 89); 3 Apr 2014 09:21:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.5 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD,SPF_HELO_PASS,T_MANY_HDRS_LCASE autolearn=ham version=3.3.2 X-HELO: mailout2.w1.samsung.com Received: from mailout2.w1.samsung.com (HELO mailout2.w1.samsung.com) (210.118.77.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (DES-CBC3-SHA encrypted) ESMTPS; Thu, 03 Apr 2014 09:20:59 +0000 Received: from eucpsbgm1.samsung.com (unknown [203.254.199.244]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N3G00LW17AMF360@mailout2.w1.samsung.com> for binutils@sourceware.org; Thu, 03 Apr 2014 10:20:46 +0100 (BST) Received: from eusync1.samsung.com ( [203.254.199.211]) by eucpsbgm1.samsung.com (EUCPMTA) with SMTP id 1E.D9.23059.6F72D335; Thu, 03 Apr 2014 10:20:54 +0100 (BST) Received: from gusevamvPC ([106.109.131.128]) by eusync1.samsung.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPA id <0N3G003PO7ATUDA0@eusync1.samsung.com>; Thu, 03 Apr 2014 10:20:54 +0100 (BST) From: Maria Guseva To: binutils@sourceware.org Cc: 'Yury Gribov' , 'Slava Garbuzov' Subject: [PATCH] Fix failure of 32-bit linker on large files Date: Thu, 03 Apr 2014 09:21:00 -0000 Message-id: <01b401cf4f1e$03c689f0$0b539dd0$%guseva@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-SW-Source: 2014-04/txt/msg00035.txt.bz2 Hi all, I've found that while linking pretty large files the bfd_seek() function may be called with incorrect negative value of argument "position". The "position" value is negative due to overflow in local variable of type long. That happens in _bfd_elf_set_section_contents(): bfd_signed_vma pos; [...] pos = hdr->sh_offset + offset; if (bfd_seek (abfd, pos, SEEK_SET) != 0 Both addends are of long long type, the result is used as long long as well. Using the long type for intermediate result seems to be a bug. That leads 32-bit linker to fail for large (~2Gb) files. The Bugzilla entry for this: https://sourceware.org/bugzilla/show_bug.cgi?id=16803 Proposed patch is attached. Regards, Maria PR ld/16803 Fixed integer overflow. * elf.c (_bfd_elf_set_section_contents): Fixed type of local variable. diff --git a/bfd/elf.c b/bfd/elf.c index 3ded683..2fee9ac 100644 --- a/bfd/elf.c +++ b/bfd/elf.c @@ -7800,7 +7800,7 @@ _bfd_elf_set_section_contents (bfd *abfd, bfd_size_type count) { Elf_Internal_Shdr *hdr; - bfd_signed_vma pos; + file_ptr pos; if (! abfd->output_has_begun && ! _bfd_elf_compute_section_file_positions (abfd, NULL))