Re: dwarf2_find_nearest_line

[Daniel Jacobowitz <drow at false dot org>]

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