* 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 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
* 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
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).