This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: dwarf2_find_nearest_line
- From: Daniel Jacobowitz <dan at debian dot org>
- To: binutils at sources dot redhat dot com
- Date: Thu, 23 Sep 2004 10:09:50 -0400
- Subject: Re: dwarf2_find_nearest_line
- References: <20040923123632.GA30257@bubble.modra.org>
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