This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Problem with DWARF2 debug info for DJGPP
- From: "Mark E." <snowball3 at softhome dot net>
- To: binutils at sources dot redhat dot com, pavenis at lanet dot lv
- Date: Sat, 10 Aug 2002 17:32:23 -0400
- Subject: Re: Problem with DWARF2 debug info for DJGPP
I figured out what's going on, but I have no idea what to do about.
> I'm getting error message about wrong DWARF2 abbrev when attemting to link
> program which contains reference to unresolved symbol
> > gcc -S -gdwarf-2 produces:
> .section .debug_info,""
> .long 0x61
> .word 0x2
> .long Ldebug_abbrev0
> .byte 0x4
> .uleb128 0x1
> .long Ldebug_line0
When ld is processing a section in the object file and discovers a symbol is
undefined, it prints a message that includes the file and line number. The
routines that do this use bfd_find_nearest_line() to get at this info. With
the testcase, 'foo' is discovered to be undefined and dwarf2 information has
been generated for it. However, the .debug_info section hasn't yet been
processed by the linker so it still has relocations. Since relocations aren't
section-relative in COFF, '.long Ldebug_abbrev0' doesn't evaluate to '.long
0' in the generated object file like it does in the equivalent ELF version.
I guess the difference between the two is because they represent relocations
somewhat differently (ELF uses section-relative relocations, COFF doesn't?).
Until someone can come up with a solution, just make a note that the dwarf2
warning message is a known problem.
Mark