From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26847 invoked by alias); 12 Mar 2009 14:25:55 -0000 Received: (qmail 26833 invoked by uid 22791); 12 Mar 2009 14:25:54 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 Mar 2009 14:25:43 +0000 Received: (qmail 18444 invoked from network); 12 Mar 2009 14:25:38 -0000 Received: from unknown (HELO ?192.168.1.102?) (ams@127.0.0.2) by mail.codesourcery.com with ESMTPA; 12 Mar 2009 14:25:38 -0000 Message-ID: <49B91B5F.9030906@codesourcery.com> Date: Thu, 12 Mar 2009 14:25:00 -0000 From: Andrew Stubbs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1b3pre) Gecko/20081204 Thunderbird/3.0b1 MIME-Version: 1.0 To: binutils@sourceware.org Subject: [PATCH] Debug info read problem Content-Type: multipart/mixed; boundary="------------030407050708010406080602" X-IsSubscribed: yes 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 X-SW-Source: 2009-03/txt/msg00223.txt.bz2 This is a multi-part message in MIME format. --------------030407050708010406080602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 1046 I have been investigating a problem in which I see this message, in addition to "undefined reference to" messages: > arm-none-eabi-ld: Dwarf Error: Offset (273) greater than or equal to .debug_str size (268). The problem is that it mis-reads the size of the .debug_str section. This leads to valid offsets appearing out-of-range. Debugging shows that the section "rawsize" field contains the correct size, but the code prefers the "size" field, which does not. It's not entirely clear to me why there would be two different sizes for this section - the comments on the fields talk about relaxation and such, but I don't understand how this related to debug info. It does say that, if set, the field contains the original size of the input section on disk. This would appear to be the right thing, in this case. The attached patch fixes the problem for the test case, but I don't if I'm fixing the symptom, or the root cause. Note that this code is usually only called for building diagnostic messages from debug info. OK? Andrew --------------030407050708010406080602 Content-Type: text/x-diff; name="section-size.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="section-size.patch" Content-length: 976 2009-03-12 Andrew Stubbs bfd/ * dwarf2.c (read_section): Always use rawsize, if available. --- src/binutils-mainline/bfd/dwarf2.c | 3 +-- 1 files changed, 1 insertion(+), 2 deletions(-) Index: src/binutils-mainline/bfd/dwarf2.c =================================================================== --- src/binutils-mainline/bfd/dwarf2.c.orig +++ src/binutils-mainline/bfd/dwarf2.c @@ -432,9 +432,9 @@ read_section (bfd * abfd, return FALSE; } + *section_size = msec->rawsize ? msec->rawsize : msec->size; if (syms) { - *section_size = msec->size; *section_buffer = bfd_simple_get_relocated_section_contents (abfd, msec, NULL, syms); if (! *section_buffer) @@ -442,7 +442,6 @@ read_section (bfd * abfd, } else { - *section_size = msec->rawsize ? msec->rawsize : msec->size; *section_buffer = bfd_malloc (*section_size); if (! *section_buffer) return FALSE; --------------030407050708010406080602--