Date:	Wed, 21 Jul 1999 17:03:02 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
cc:	djgpp AT delorie DOT com
Subject:	Re: Bizarre debugging format problem
In-Reply-To:	<Pine.LNX.3.93.990721130409.202B-100000@acp3bf>
Message-ID:	<Pine.SUN.3.91.990721165300.429D-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 21 Jul 1999, Hans-Bernhard Broeker wrote:

> Not totally. It just assumes the wrong 'base' address to translate the
> offsets found in the symbols to code addresses and vice versa.

That's not what I saw in my testing.  When passed an address in a function
compiled with -gcoff, it usually returns correct source file and line
information.  As far as I could see, it correctly takes the base line
number for a function from the first line info symbol for that function. 
But when faced with address in a function compiled without -g, it goes
bananas. 

> I've always wondered how on earth GDB manages to get this right,
> given that the BFD function is clearly buggy.

In the same way our libdbg.a does it: it simply doesn't use the 
xxx_find_nearest_line functions from BFD.  Instead, it reads the symbols 
via BFD, and then processes them, including the line number info, using 
its own code.

> Maybe it detects this
> (constant) offset by comparing the addresses found in function entry
> symbols with the ones for the first line number in each function
> (they're stored relative to function start), or something like that.

coff_find_nearest_line does that as well.  I suspect that it errs when it 
falls off the end of the end of the loops that search the symtab for the 
nearest function and line number.  But that's a hunch at best, and even 
it doesn't explain some of the creative output I've seen from "nm --lines".

- Raw text -