PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly

PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly

[H. J. Lu]

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


H.J.
--
2006-09-19  H.J. Lu  <hongjiu.lu@intel.com>

	PR ld/3191
	* dwarf2.c (read_attribute_value): Properly handle
	DW_FORM_ref_addr.

--- bfd/dwarf2.c.ref_addr	2006-05-02 03:01:56.000000000 -0700
+++ bfd/dwarf2.c	2006-09-19 21:26:37.000000000 -0700
@@ -562,11 +562,16 @@ read_attribute_value (struct attribute *
   switch (form)
     {
     case DW_FORM_addr:
-      /* FIXME: DWARF3 draft says DW_FORM_ref_addr is offset_size.  */
-    case DW_FORM_ref_addr:
       attr->u.val = read_address (unit, info_ptr);
       info_ptr += unit->addr_size;
       break;
+    case DW_FORM_ref_addr:
+      if (unit->offset_size == 4)
+	attr->u.val = read_4_bytes (abfd, info_ptr);
+      else
+	attr->u.val = read_8_bytes (abfd, info_ptr);
+      info_ptr += unit->offset_size;
+      break;
     case DW_FORM_block2:
       amt = sizeof (struct dwarf_block);
       blk = bfd_alloc (abfd, amt);

Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly

[H. J. Lu]

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
> 
> 
> H.J.
> --
> 2006-09-19  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	PR ld/3191
> 	* dwarf2.c (read_attribute_value): Properly handle
> 	DW_FORM_ref_addr.
> 
> --- bfd/dwarf2.c.ref_addr	2006-05-02 03:01:56.000000000 -0700
> +++ bfd/dwarf2.c	2006-09-19 21:26:37.000000000 -0700
> @@ -562,11 +562,16 @@ read_attribute_value (struct attribute *
>    switch (form)
>      {
>      case DW_FORM_addr:
> -      /* FIXME: DWARF3 draft says DW_FORM_ref_addr is offset_size.  */
> -    case DW_FORM_ref_addr:
>        attr->u.val = read_address (unit, info_ptr);
>        info_ptr += unit->addr_size;
>        break;
> +    case DW_FORM_ref_addr:
> +      if (unit->offset_size == 4)
> +	attr->u.val = read_4_bytes (abfd, info_ptr);
> +      else
> +	attr->u.val = read_8_bytes (abfd, info_ptr);
> +      info_ptr += unit->offset_size;
> +      break;
>      case DW_FORM_block2:
>        amt = sizeof (struct dwarf_block);
>        blk = bfd_alloc (abfd, amt);

We should only do it for DWARF3. But gcc generates DWARF3 info in
a DWARF2 file.


H.J.

Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly

[Daniel Jacobowitz]

On Tue, Sep 19, 2006 at 10:20:10PM -0700, H. J. Lu wrote:
> We should only do it for DWARF3. But gcc generates DWARF3 info in
> a DWARF2 file.

If GCC is using the DWARF3 convention in a DWARF2 file, please fix GCC
instead.

-- 
Daniel Jacobowitz
CodeSourcery

Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly

[Jim Wilson]

On Tue, 2006-09-19 at 22:20 -0700, H. J. Lu wrote:
> We should only do it for DWARF3. But gcc generates DWARF3 info in
> a DWARF2 file.

In DWARF2, the offset size is always 4, so there is no conflict here.
This code will work fine for both DWARF2 and DWARF3.

I do see a problem though, which is that I don't understand where the
64-bit DWARF3 is coming from.  Gcc does not emit 64-bit DWARF for any
target except Irix5/6, and the bug report does not say anything about
using a custom modified gcc.  I looked at the client.o object file in
the bug report, and there is no 64-bit DWARF there.  (The pointers are
64-bit, but the debug info offsets are not.)  I don't understand how
this patch can help.  There is something that hasn't been explained here
yet.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly

[H. J. Lu]

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.


H.J.
----
2006-09-19  H.J. Lu  <hongjiu.lu@intel.com>

	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 15:15:17.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))
 	{
@@ -2398,9 +2418,15 @@ _bfd_dwarf2_find_nearest_line (bfd *abfd
 	  stash->info_ptr_end = stash->info_ptr + start + size;
 	}
 
+      /* Restore section vma. */
+      for (msec = first_msec;
+	   msec;
+	   msec = find_debug_info (abfd, msec))
+	msec->vma = 0;
+
       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;
     }

Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly

[H. J. Lu]

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  <hongjiu.lu@intel.com>

	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;
     }

Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly

[H. J. Lu]

On Wed, Sep 20, 2006 at 05:54:11PM -0700, H. J. Lu wrote:
> 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?
> 
> 

We do need to reset section vma to 0 since it may be just a warning and
we may generate an executable.

H.J.
---
2006-09-21  H.J. Lu  <hongjiu.lu@intel.com>

	PR ld/3191
	* dwarf2.c (_bfd_dwarf2_find_nearest_line): Adjust debug_info
	section vma when needed.

--- bfd/dwarf2.c.ref_addr	2006-09-16 19:44:38.000000000 -0700
+++ bfd/dwarf2.c	2006-09-21 08:01:13.000000000 -0700
@@ -2375,6 +2375,11 @@ _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;
+      asection **msecs = NULL;
+      unsigned int i, count;
 
       *pinfo = stash;
 
@@ -2389,9 +2394,28 @@ _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;
+      count = 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->vma == 0 && msec->alignment_power == 0);
+
+	  msec->vma = last_vma;
+	  last_vma += size;
+	  count++;
+	}
 
       stash->info_ptr = bfd_alloc (abfd, total_size);
       if (stash->info_ptr == NULL)
@@ -2399,17 +2423,27 @@ _bfd_dwarf2_find_nearest_line (bfd *abfd
 
       stash->info_ptr_end = stash->info_ptr;
 
-      for (msec = find_debug_info (abfd, NULL);
+      if (count > 1)
+	{
+	  count--;
+	  msecs = (asection **) bfd_malloc2 (count, sizeof (*msecs));
+	}
+
+      for (i = 0, msec = first_msec;
 	   msec;
 	   msec = find_debug_info (abfd, msec))
 	{
-	  bfd_size_type size;
 	  bfd_size_type start;
 
 	  size = msec->size;
 	  if (size == 0)
 	    continue;
 
+	  if (i && msecs)
+	    msecs [i - 1] = msec;
+
+	  i++;
+
 	  start = stash->info_ptr_end - stash->info_ptr;
 
 	  if ((bfd_simple_get_relocated_section_contents
@@ -2419,9 +2453,27 @@ _bfd_dwarf2_find_nearest_line (bfd *abfd
 	  stash->info_ptr_end = stash->info_ptr + start + size;
 	}
 
+      /* Restore section vma. */
+      if (count)
+	{
+	  if (msecs)
+	    {
+	      for (i = 0; i < count; i++)
+		msecs [i]->vma = 0;
+	      free (msecs);
+	    }
+	  else
+	    {
+	      for (msec = find_debug_info (abfd, first_msec);
+		   msec;
+		   msec = find_debug_info (abfd, msec))
+		msec->vma = 0;
+	    }
+	}
+
       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;
     }

Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly

[Jim Wilson]

On Thu, 2006-09-21 at 08:03 -0700, H. J. Lu wrote:
> 	PR ld/3191
> 	* dwarf2.c (_bfd_dwarf2_find_nearest_line): Adjust debug_info
> 	section vma when needed.

I'm willing to review a patch for this bug report, but I am still unable
to reproduce the bug, same as last week.  I tried the object files in
the bug report, but I can't get them to fail.  I also went so far as to
try to build kdesvn, but gave up because it required too many other
unfamiliar packages.

How are you debugging this?
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly

[H. J. Lu]

On Wed, Sep 27, 2006 at 05:21:15PM -0700, Jim Wilson wrote:
> On Thu, 2006-09-21 at 08:03 -0700, H. J. Lu wrote:
> > 	PR ld/3191
> > 	* dwarf2.c (_bfd_dwarf2_find_nearest_line): Adjust debug_info
> > 	section vma when needed.
> 
> I'm willing to review a patch for this bug report, but I am still unable
> to reproduce the bug, same as last week.  I tried the object files in
> the bug report, but I can't get them to fail.  I also went so far as to
> try to build kdesvn, but gave up because it required too many other
> unfamiliar packages.
> 
> How are you debugging this?

It is very sensitive to environment. I can reproduce it on an upto 
date Fedora Core 5 EM64T machine with 2GB RAM.


H.J.

Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly

[Jim Wilson]

How do I reproduce the problem?  I just get undefined linker errors when
I try to link the client.o file.

Do you know where the 64-bit DWARF is coming from?  Which object file
section is this in?  I haven't been able to find any 64-bit DWARF info
yet.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly

[H. J. Lu]

On Wed, Sep 20, 2006 at 12:01:18PM -0700, Jim Wilson wrote:
> How do I reproduce the problem?  I just get undefined linker errors when
> I try to link the client.o file.
> 
> Do you know where the 64-bit DWARF is coming from?  Which object file
> section is this in?  I haven't been able to find any 64-bit DWARF info
> yet.

I think it is a linker dwarf reader problem. Gcc may generate:

         .section .gnu.linkonce.wi.client.cpp.7682538d,"",@progbits
         ...
DW.client.cpp.7682538d.2b:
        .uleb128 0xd
        .long   0x16a
        .byte   0x1
        .long   .LASF10
        .byte   0x1
        .byte   0x25
        .byte   0x1
        .uleb128 0xe
        .long   0x114
        .byte   0x1
        .byte   0x0


        .section        .debug_info
        ...
        .uleb128 0x8d
        .long   0x1c3f
        .quad   DW.client.cpp.7682538d.2b
        .byte   0x0

When reporting linker error, dwarf2 reader assumes that there is only
one .debug_info section. DW_FORM_ref_addr reference to
DW.client.cpp.7682538d.2b isn't handled properly.


H.J.