* PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly @ 2006-09-20 6:16 H. J. Lu 2006-09-20 11:40 ` H. J. Lu 2006-09-20 19:59 ` Jim Wilson 0 siblings, 2 replies; 11+ messages in thread From: H. J. Lu @ 2006-09-20 6:16 UTC (permalink / raw) To: binutils 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); ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly 2006-09-20 6:16 PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly H. J. Lu @ 2006-09-20 11:40 ` H. J. Lu 2006-09-20 14:48 ` Daniel Jacobowitz ` (2 more replies) 2006-09-20 19:59 ` Jim Wilson 1 sibling, 3 replies; 11+ messages in thread From: H. J. Lu @ 2006-09-20 11:40 UTC (permalink / raw) To: binutils 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly 2006-09-20 11:40 ` H. J. Lu @ 2006-09-20 14:48 ` Daniel Jacobowitz 2006-09-20 19:15 ` Jim Wilson 2006-09-20 22:32 ` H. J. Lu 2 siblings, 0 replies; 11+ messages in thread From: Daniel Jacobowitz @ 2006-09-20 14:48 UTC (permalink / raw) To: H. J. Lu; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly 2006-09-20 11:40 ` H. J. Lu 2006-09-20 14:48 ` Daniel Jacobowitz @ 2006-09-20 19:15 ` Jim Wilson 2006-09-20 22:32 ` H. J. Lu 2 siblings, 0 replies; 11+ messages in thread From: Jim Wilson @ 2006-09-20 19:15 UTC (permalink / raw) To: H. J. Lu; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly 2006-09-20 11:40 ` H. J. Lu 2006-09-20 14:48 ` Daniel Jacobowitz 2006-09-20 19:15 ` Jim Wilson @ 2006-09-20 22:32 ` H. J. Lu 2006-09-21 2:10 ` H. J. Lu 2 siblings, 1 reply; 11+ messages in thread From: H. J. Lu @ 2006-09-20 22:32 UTC (permalink / raw) To: binutils 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; } ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly 2006-09-20 22:32 ` H. J. Lu @ 2006-09-21 2:10 ` H. J. Lu 2006-09-21 16:23 ` H. J. Lu 0 siblings, 1 reply; 11+ messages in thread From: H. J. Lu @ 2006-09-21 2:10 UTC (permalink / raw) To: binutils 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; } ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly 2006-09-21 2:10 ` H. J. Lu @ 2006-09-21 16:23 ` H. J. Lu 2006-09-28 7:45 ` Jim Wilson 0 siblings, 1 reply; 11+ messages in thread From: H. J. Lu @ 2006-09-21 16:23 UTC (permalink / raw) To: binutils 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; } ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly 2006-09-21 16:23 ` H. J. Lu @ 2006-09-28 7:45 ` Jim Wilson 2006-09-28 9:08 ` H. J. Lu 0 siblings, 1 reply; 11+ messages in thread From: Jim Wilson @ 2006-09-28 7:45 UTC (permalink / raw) To: H. J. Lu; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly 2006-09-28 7:45 ` Jim Wilson @ 2006-09-28 9:08 ` H. J. Lu 0 siblings, 0 replies; 11+ messages in thread From: H. J. Lu @ 2006-09-28 9:08 UTC (permalink / raw) To: Jim Wilson; +Cc: binutils 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly 2006-09-20 6:16 PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly H. J. Lu 2006-09-20 11:40 ` H. J. Lu @ 2006-09-20 19:59 ` Jim Wilson 2006-09-20 20:02 ` H. J. Lu 1 sibling, 1 reply; 11+ messages in thread From: Jim Wilson @ 2006-09-20 19:59 UTC (permalink / raw) To: H. J. Lu; +Cc: binutils 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly 2006-09-20 19:59 ` Jim Wilson @ 2006-09-20 20:02 ` H. J. Lu 0 siblings, 0 replies; 11+ messages in thread From: H. J. Lu @ 2006-09-20 20:02 UTC (permalink / raw) To: Jim Wilson; +Cc: binutils 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-09-28 1:25 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-09-20 6:16 PATCH: PR ld/3191: Linker failed to handle DW_FORM_ref_addr properly H. J. Lu 2006-09-20 11:40 ` H. J. Lu 2006-09-20 14:48 ` Daniel Jacobowitz 2006-09-20 19:15 ` Jim Wilson 2006-09-20 22:32 ` H. J. Lu 2006-09-21 2:10 ` H. J. Lu 2006-09-21 16:23 ` H. J. Lu 2006-09-28 7:45 ` Jim Wilson 2006-09-28 9:08 ` H. J. Lu 2006-09-20 19:59 ` Jim Wilson 2006-09-20 20:02 ` H. J. Lu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).