dwarf2_find_nearest_line

dwarf2_find_nearest_line

[Alan Modra]

Continuing http://sources.redhat.com/ml/binutils/2004-08/msg00095.html

I'd say _bfd_dwarf2_find_nearest_line is quite broken when it is trying
to work on relocatable object files.  VMAs for all sections are zero in
relocatable files, thus the "address" that comp_unit_contains_address 
tests is just a section offset.  In the powerpc64 testcase above, the
undef4.o(.toc+0x8) reference results in comp_unit_contains_address
looking for an "address" of 8, which happens to match debug info for
the text section.  That's how we get a wrong reference to
/src/tmp/undef1.c:5.

So, what happens if we are linking an object file with many text
sections, for example when using -ffunction-sections?  Total confusion,
I think..

Of course, if we're using _bfd_dwarf2_find_nearest_line to output
error messages for the linker, we have the final section VMAs available.
However, bfd_simple_get_relocated_section_contents seems to go out of
it's way to zero input section vmas.  Why?

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: dwarf2_find_nearest_line

[Daniel Jacobowitz]

On Thu, Sep 23, 2004 at 10:06:32PM +0930, Alan Modra wrote:
> Continuing http://sources.redhat.com/ml/binutils/2004-08/msg00095.html
> 
> I'd say _bfd_dwarf2_find_nearest_line is quite broken when it is trying
> to work on relocatable object files.  VMAs for all sections are zero in
> relocatable files, thus the "address" that comp_unit_contains_address 
> tests is just a section offset.  In the powerpc64 testcase above, the
> undef4.o(.toc+0x8) reference results in comp_unit_contains_address
> looking for an "address" of 8, which happens to match debug info for
> the text section.  That's how we get a wrong reference to
> /src/tmp/undef1.c:5.
> 
> So, what happens if we are linking an object file with many text
> sections, for example when using -ffunction-sections?  Total confusion,
> I think..
> 
> Of course, if we're using _bfd_dwarf2_find_nearest_line to output
> error messages for the linker, we have the final section VMAs available.
> However, bfd_simple_get_relocated_section_contents seems to go out of
> it's way to zero input section vmas.  Why?

No, it doesn't touch input VMAs - just the output offsets.  It has to
temporarily clobber the output offsets, because of the problem
described in the comments.  The problem is that we're looking at
sections in the input object to issue the error message.

Take a look at a sample CU header generated by GCC:
        .section        .debug_info
        .long   0x116e  # Length of Compilation Unit Info
        .value  0x2     # DWARF version number
        .long   .Ldebug_abbrev0 # Offset Into Abbrev. Section
        .byte   0x4     # Pointer Size (in bytes)

.Ldebug_abbrev0 is defined in this object's .debug_abbrev, but the
field is an offset into .debug_abbrev.  Since we will look for it in
this object's .debug_abbrev, we need to place the section at the
correct address - which is 0.

If you want to find the right CU for the error message, you're probably
going to need to grok through the relocations to figure out which
section is being pointed to.  This is conceptually pretty easy, but BFD
doesn't offer a good interface for it.

-- 
Daniel Jacobowitz

Re: dwarf2_find_nearest_line

[Alan Modra]

On Thu, Sep 23, 2004 at 10:09:50AM -0400, Daniel Jacobowitz wrote:
> No, it doesn't touch input VMAs - just the output offsets.  It has to

Yes, sorry, I meant output offset and output section vma, and it's these
two that are used in calculating symbol values.

> temporarily clobber the output offsets, because of the problem
> described in the comments.  The problem is that we're looking at
> sections in the input object to issue the error message.
> 
> Take a look at a sample CU header generated by GCC:
>         .section        .debug_info
>         .long   0x116e  # Length of Compilation Unit Info
>         .value  0x2     # DWARF version number
>         .long   .Ldebug_abbrev0 # Offset Into Abbrev. Section
>         .byte   0x4     # Pointer Size (in bytes)
> 
> .Ldebug_abbrev0 is defined in this object's .debug_abbrev, but the
> field is an offset into .debug_abbrev.  Since we will look for it in
> this object's .debug_abbrev, we need to place the section at the
> correct address - which is 0.
> 
> If you want to find the right CU for the error message, you're probably
> going to need to grok through the relocations to figure out which
> section is being pointed to.  This is conceptually pretty easy, but BFD
> doesn't offer a good interface for it.

Okayyy.  So you really only need to zap debug sections.  If we left
other sections alone, then we'd properly calculate pc ranges in FDEs as
per the final exe.  That allows multiple input text sections to be
descriminated according to their final addresses.  I think..  I'll
have a go at it tomorrow.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: dwarf2_find_nearest_line

[Daniel Jacobowitz]

On Fri, Sep 24, 2004 at 12:01:57AM +0930, Alan Modra wrote:
> On Thu, Sep 23, 2004 at 10:09:50AM -0400, Daniel Jacobowitz wrote:
> > No, it doesn't touch input VMAs - just the output offsets.  It has to
> 
> Yes, sorry, I meant output offset and output section vma, and it's these
> two that are used in calculating symbol values.
> 
> > temporarily clobber the output offsets, because of the problem
> > described in the comments.  The problem is that we're looking at
> > sections in the input object to issue the error message.
> > 
> > Take a look at a sample CU header generated by GCC:
> >         .section        .debug_info
> >         .long   0x116e  # Length of Compilation Unit Info
> >         .value  0x2     # DWARF version number
> >         .long   .Ldebug_abbrev0 # Offset Into Abbrev. Section
> >         .byte   0x4     # Pointer Size (in bytes)
> > 
> > .Ldebug_abbrev0 is defined in this object's .debug_abbrev, but the
> > field is an offset into .debug_abbrev.  Since we will look for it in
> > this object's .debug_abbrev, we need to place the section at the
> > correct address - which is 0.
> > 
> > If you want to find the right CU for the error message, you're probably
> > going to need to grok through the relocations to figure out which
> > section is being pointed to.  This is conceptually pretty easy, but BFD
> > doesn't offer a good interface for it.
> 
> Okayyy.  So you really only need to zap debug sections.  If we left
> other sections alone, then we'd properly calculate pc ranges in FDEs as
> per the final exe.  That allows multiple input text sections to be
> descriminated according to their final addresses.  I think..  I'll
> have a go at it tomorrow.

Yeah, that might work.  Will that help for the relocatable link problem
though?

-- 
Daniel Jacobowitz

Re: dwarf2_find_nearest_line

[Alan Modra]

On Fri, Sep 24, 2004 at 12:01:57AM +0930, Alan Modra wrote:
> other sections alone, then we'd properly calculate pc ranges in FDEs as

Ignore the reference to FDEs.  I've got FDEs on the brain.  Lots of
messing with eh_frame recently.  ;-)

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: dwarf2_find_nearest_line

[Alan Modra]

On Thu, Sep 23, 2004 at 10:41:00AM -0400, Daniel Jacobowitz wrote:
> On Fri, Sep 24, 2004 at 12:01:57AM +0930, Alan Modra wrote:
> > Okayyy.  So you really only need to zap debug sections.  If we left
> > other sections alone, then we'd properly calculate pc ranges in FDEs as
> > per the final exe.  That allows multiple input text sections to be
> > descriminated according to their final addresses.  I think..  I'll
> > have a go at it tomorrow.
> 
> Yeah, that might work.  Will that help for the relocatable link problem
> though?

Should do.  I threw together a quick hack and it's looking good.  I'll
post it tomorrow.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: dwarf2_find_nearest_line

[Alan Modra]

On Fri, Sep 24, 2004 at 12:34:28AM +0930, Alan Modra wrote:
> On Thu, Sep 23, 2004 at 10:41:00AM -0400, Daniel Jacobowitz wrote:
> > On Fri, Sep 24, 2004 at 12:01:57AM +0930, Alan Modra wrote:
> > > Okayyy.  So you really only need to zap debug sections.  If we left
> > > other sections alone, then we'd properly calculate pc ranges in FDEs as
> > > per the final exe.  That allows multiple input text sections to be
> > > descriminated according to their final addresses.  I think..  I'll
> > > have a go at it tomorrow.

Committed.  The testsuite change is because the undefined references
on powerpc64-linux are in the TOC section.  Since we don't emit
debug info for the TOC, _bfd_dwarf2_find_nearest_line now correctly
does not return a bogus file, function, and line.

bfd/
	* dwarf2.c (_bfd_dwarf2_find_nearest_line): Add output section
	vma and output offset to address.
	* simple.c (simple_save_output_info): Only set output section
	and offset for debug sections, or those not already set up by
	the linker.
	(bfd_simple_get_relocated_section_contents): Update comment.
ld/testsuite/
	* ld-elfvsb/elfvsb.exp: Remove file name from "undefined ref" string.

Index: bfd/dwarf2.c
===================================================================
RCS file: /cvs/src/src/bfd/dwarf2.c,v
retrieving revision 1.57
diff -u -p -r1.57 dwarf2.c
--- bfd/dwarf2.c	24 Jun 2004 04:46:16 -0000	1.57
+++ bfd/dwarf2.c	24 Sep 2004 03:37:41 -0000
@@ -1703,13 +1703,19 @@ _bfd_dwarf2_find_nearest_line (bfd *abfd
      We keep a list of all the previously read compilation units, and
      a pointer to the next un-read compilation unit.  Check the
      previously read units before reading more.  */
-  struct dwarf2_debug *stash = *pinfo;
+  struct dwarf2_debug *stash;
 
   /* What address are we looking for?  */
-  bfd_vma addr = offset + section->vma;
+  bfd_vma addr;
 
   struct comp_unit* each;
 
+  stash = *pinfo;
+  addr = offset;
+  if (section->output_section)
+    addr += section->output_section->vma + section->output_offset;
+  else
+    addr += section->vma;
   *filename_ptr = NULL;
   *functionname_ptr = NULL;
   *linenumber_ptr = 0;
Index: bfd/simple.c
===================================================================
RCS file: /cvs/src/src/bfd/simple.c,v
retrieving revision 1.17
diff -u -p -r1.17 simple.c
--- bfd/simple.c	29 Jun 2004 14:13:44 -0000	1.17
+++ bfd/simple.c	24 Sep 2004 03:37:41 -0000
@@ -92,8 +92,12 @@ simple_save_output_info (bfd *abfd ATTRI
   struct saved_output_info *output_info = ptr;
   output_info[section->index].offset = section->output_offset;
   output_info[section->index].section = section->output_section;
-  section->output_offset = 0;
-  section->output_section = section;
+  if ((section->flags & SEC_DEBUGGING) != 0
+      || section->output_section == NULL)
+    {
+      section->output_offset = 0;
+      section->output_section = section;
+    }
 }
 
 static void
@@ -117,13 +121,10 @@ SYNOPSIS
 DESCRIPTION
 	Returns the relocated contents of section @var{sec}.  The symbols in
 	@var{symbol_table} will be used, or the symbols from @var{abfd} if
-	@var{symbol_table} is NULL.  The output offsets for all sections will
+	@var{symbol_table} is NULL.  The output offsets for debug sections will
 	be temporarily reset to 0.  The result will be stored at @var{outbuf}
 	or allocated with @code{bfd_malloc} if @var{outbuf} is @code{NULL}.
 
-	Generally all sections in @var{abfd} should have their
-	@code{output_section} pointing back to the original section.
-
 	Returns @code{NULL} on a fatal error; ignores errors applying
 	particular relocations.
 */
Index: ld/testsuite/ld-elfvsb/elfvsb.exp
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-elfvsb/elfvsb.exp,v
retrieving revision 1.26
diff -u -p -r1.26 elfvsb.exp
--- ld/testsuite/ld-elfvsb/elfvsb.exp	17 Aug 2004 05:39:32 -0000	1.26
+++ ld/testsuite/ld-elfvsb/elfvsb.exp	24 Sep 2004 05:22:26 -0000
@@ -117,12 +117,12 @@ proc visibility_test { visibility progna
     }
     if {![ld_simple_link $CC $tmpdir/$progname.so "$shared $shldflags $tmpdir/$sh1 $tmpdir/$sh2"]} {
 	if { [ string match $visibility "hidden_undef" ]
-	     && [regexp ".*/sh1.c.*: undefined reference to \`\.?visibility\'" $link_output]
-	     && [regexp ".*/sh1.c.*: undefined reference to \`visibility_var\'" $link_output] } {
+	     && [regexp "undefined reference to \`\.?visibility\'" $link_output]
+	     && [regexp "undefined reference to \`visibility_var\'" $link_output] } {
     	    pass "$testname"
 	} else { if { [ string match $visibility "protected_undef" ]
-	     && [regexp ".*/sh1.c.*: undefined reference to \`\.?visibility\'" $link_output]
-	     && [regexp ".*/sh1.c.*: undefined reference to \`visibility_var\'" $link_output] } {
+	     && [regexp "undefined reference to \`\.?visibility\'" $link_output]
+	     && [regexp "undefined reference to \`visibility_var\'" $link_output] } {
     	    pass "$testname"
 	} else {
 	    fail "$testname"
@@ -140,14 +140,14 @@ proc visibility_test { visibility progna
     }
     if ![ld_simple_link $CC $tmpdir/$progname "-Wl,-rpath,$rpath $tmpdir/$main $tmpdir/$progname.so"] {
 	if { [ string match $visibility "hidden" ]
-	     && [regexp ".*/main.c.*: undefined reference to \`\.?visibility\'" $link_output]
-	     && [regexp ".*/main.c.*: undefined reference to \`visibility_var\'" $link_output] } {
+	     && [regexp "undefined reference to \`\.?visibility\'" $link_output]
+	     && [regexp "undefined reference to \`visibility_var\'" $link_output] } {
     	    pass "$testname"
 	} else { if { [ string match $visibility "hidden_undef_def" ]
-	     && [regexp ".*/main.c.*: undefined reference to \`\.?visibility\'" $link_output]
-	     && [regexp ".*/main.c.*: undefined reference to \`visibility_def\'" $link_output]
-	     && [regexp ".*/main.c.*: undefined reference to \`\.?visibility_func\'" $link_output]
-	     && [regexp ".*/main.c.*: undefined reference to \`visibility_var\'" $link_output] } {
+	     && [regexp "undefined reference to \`\.?visibility\'" $link_output]
+	     && [regexp "undefined reference to \`visibility_def\'" $link_output]
+	     && [regexp "undefined reference to \`\.?visibility_func\'" $link_output]
+	     && [regexp "undefined reference to \`visibility_var\'" $link_output] } {
     	    pass "$testname"
 	} else {
     	    fail "$testname"

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre