Mail Archives: djgpp-workers/2002/08/12/07:30:18
On 10 Aug 2002 at 17:32, Mark E. wrote:
> 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.
>
My last experience shows that DWARF2 debugging info already is most stable
for debugging, so I would like to change to it to be the default in next DJGPP
release of GCC. As result many novice users who don't read corresponding
readme files (sadly, but true) will run into this harmless problem and flood
mailing list with questions.
Seems that _bfd_dwarf2_find_nearest_line doesn't provide us any reasonable
info in case of this error, so maybe it could be better to remove temporary
this call at all (perhaps '#if 0' and "#endif") for DJGPP release of binutils-
2.13
Andris
- Raw text -