_bfd_dwarf2_find_nearest_line returns wrong filename
Andreas Schwab
schwab@suse.de
Mon Dec 30 17:15:00 GMT 2002
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.
More information about the Binutils
mailing list