Re: _bfd_dwarf2_find_nearest_line returns wrong filename

[Andreas Schwab <schwab at suse dot de>]

Nick Clifton <nickc@redhat.com> writes:

> > 2002-12-23  Andreas Schwab  <schwab@suse.de>
> > 
> > 	* dwarf2.c (struct dwarf2_debug): Add relocs and reloc_count.
> > 	(find_rela_addend): Take pointer to struct dwarf2_debug instead of
> > 	section and symbols.  Cache reloc section there.  Don't check
> > 	section in reloc, just compare offset.
> > 	(read_indirect_string): Use find_rela_addend to relocate string
> > 	offset.
> > 	(parse_comp_unit): Adjust call to find_rela_addend.  Don't
> > 	advance to next debug section until after
> > 	comp_unit_find_nearest_line has been called.
> 
> Approved - please apply.

Unfortunately this has a two problems.  First, on ppc, while being a
RELA target, the addend is also stored in the section contents.  This
can be fixed by using the RELA addend in preference to the value read
from the section, which I believe is correct for all RELA targets.  On
m68k, where I initially tested this, the section contents are zeroed,
so the bug does not occur.  The other problem occurs when reusing a
previously read compilation unit, in which case the section pointer in
struct dwarf2_debug may be pointing to an unrelated section or can
even be NULL (when all debug section have already been read).  I
haven't yet found an easy way to solve that properly.

> Also - is it safe to drop the test of the reloc's symbol pointer ?

I believe this is safe since we are only looking at specific entries
in the .debug_info section that are offsets into either the
.debug_abbrev or the .debug_str section.  But maybe at least the check
for a section symbol should be readded.

> Finally - would it be possible to develop a testcase to check the
> patch's behaviour ?

This looks difficult since it requires synthesizing the rather complex
debug sections in a generic way, unless you want to depend on the
compiler or assembler to produce it for you.  But once this is done
something involving "nm -l" could perhaps be used.

Andreas.