From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9809 invoked by alias); 21 Sep 2006 00:54:17 -0000 Received: (qmail 9794 invoked by uid 22791); 21 Sep 2006 00:54:16 -0000 X-Spam-Check-By: sourceware.org Received: from smtp109.sbc.mail.mud.yahoo.com (HELO smtp109.sbc.mail.mud.yahoo.com) (68.142.198.208) by sourceware.org (qpsmtpd/0.31) with SMTP; Thu, 21 Sep 2006 00:54:14 +0000 Received: (qmail 21584 invoked from network); 21 Sep 2006 00:54:12 -0000 Received: from unknown (HELO lucon.org) (hjjean@sbcglobal.net@71.146.100.252 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 21 Sep 2006 00:54:12 -0000 Received: by lucon.org (Postfix, from userid 500) id 4AC12105B5; Wed, 20 Sep 2006 17:54:11 -0700 (PDT) Date: Thu, 21 Sep 2006 02:10:00 -0000 From: "H. J. Lu" To: binutils@sources.redhat.com Subject: Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly Message-ID: <20060921005411.GA3401@lucon.org> References: <20060920043701.GA24160@lucon.org> <20060920052010.GA22345@lucon.org> <20060920221922.GA2385@lucon.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060920221922.GA2385@lucon.org> User-Agent: Mutt/1.4.2.1i Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00213.txt.bz2 On Wed, Sep 20, 2006 at 03:19:22PM -0700, H. J. Lu wrote: > On Tue, Sep 19, 2006 at 10:20:10PM -0700, H. J. Lu wrote: > > On Tue, Sep 19, 2006 at 09:37:02PM -0700, H. J. Lu wrote: > > > DW_FORM_ref_addr is offset_size according to DWARF3 and gcc follows > > > DWARF3. This patch fixes > > > > > > http://sourceware.org/bugzilla/show_bug.cgi?id=3191 > > > > > > > > It turns out that the problem is we didn't properly adjust debug_info > section vmas when we put them together. I think this is a right fix. > > Here is the updated patch. Can we assume debug section vma is 0 and we don't need to reset it after adjustment and relocation? H.J. 2006-09-19 H.J. Lu PR ld/3191 * dwarf2.c (_bfd_dwarf2_find_nearest_line): Adjust debug_info section vma when needed. --- bfd/dwarf2.c.ref_addr 2006-05-02 03:01:56.000000000 -0700 +++ bfd/dwarf2.c 2006-09-20 17:46:05.000000000 -0700 @@ -2354,6 +2354,9 @@ _bfd_dwarf2_find_nearest_line (bfd *abfd { bfd_size_type total_size; asection *msec; + bfd_vma last_vma; + bfd_size_type size; + asection *first_msec; *pinfo = stash; @@ -2368,9 +2371,26 @@ _bfd_dwarf2_find_nearest_line (bfd *abfd Read them all in and produce one large stash. We do this in two passes - in the first pass we just accumulate the section sizes. In the second pass we read in the section's contents. The allows - us to avoid reallocing the data as we add sections to the stash. */ + us to avoid reallocing the data as we add sections to the stash. + + We may need to adjust debug_info section vmas since we will + concatenate them together. Otherwise relocations may be + incorrect. */ + first_msec = msec; + last_vma = 0; for (total_size = 0; msec; msec = find_debug_info (abfd, msec)) - total_size += msec->size; + { + size = msec->size; + if (size == 0) + continue; + + total_size += size; + + BFD_ASSERT (msec->alignment_power == 0); + + msec->vma = last_vma; + last_vma += size; + } stash->info_ptr = bfd_alloc (abfd, total_size); if (stash->info_ptr == NULL) @@ -2378,7 +2398,7 @@ _bfd_dwarf2_find_nearest_line (bfd *abfd stash->info_ptr_end = stash->info_ptr; - for (msec = find_debug_info (abfd, NULL); + for (msec = first_msec; msec; msec = find_debug_info (abfd, msec)) { @@ -2400,7 +2420,7 @@ _bfd_dwarf2_find_nearest_line (bfd *abfd BFD_ASSERT (stash->info_ptr_end == stash->info_ptr + total_size); - stash->sec = find_debug_info (abfd, NULL); + stash->sec = first_msec; stash->sec_info_ptr = stash->info_ptr; stash->syms = symbols; }