This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]