Re: dwarf2_find_nearest_line

[Alan Modra <amodra at bigpond dot net dot au>]

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