From: pavenis AT lanet DOT lv
To: "Mark E." <snowball3 AT softhome DOT net>
Date: Mon, 12 Aug 2002 14:27:35 +0300
MIME-Version: 1.0
Subject: Re: Problem with DWARF2 debug info for DJGPP
Cc: djgpp-workers AT delorie DOT com
Message-ID: <3D57C5D7.23156.20C047@localhost>
In-reply-to: <3D554E27.6498.1979079@localhost>
X-mailer: Pegasus Mail for Windows (v4.02)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Content-description: Mail message body
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

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