This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: dwarf2_find_nearest_line


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]