Date: Wed, 21 Jul 1999 10:51:13 +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.990720153851.212G-100000@acp3bf>
Message-ID: <Pine.SUN.3.91.990721105028.7757C-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Tue, 20 Jul 1999, Hans-Bernhard Broeker wrote:

> To put this in context: no, I haven't ever seen this problem with *gdb*,
> only with binutils themselves (objdump -dl, gprof).

As far as I could see, the BFD function that fetches file names and
source line numbers from COFF debugging info is totally broken.  It
fails spectacularly for modules compiled without -g, like library
functions, but also has some ``interesting'' surprises for functions
compiled with -g.  All programs from Binutils exhibit the same
problems with line numbers, because they all call that single
function.  You can use addr2line as the simple testbed.  Stabs
debugging uses a different function to fetch source line info.

But GDB doesn't rely on BFD alone for the symtab management, it has
its own, highly complex code that evidently fixes the problems,
because I never saw GDB err or lie about source lines.

So I don't think this is in any way relevant to GDB, no matter what
GDB build is that.

> I'm currently in the process of packaging up the changes I need for full
> applicability of 'gprof'.

Do these changes fix the line info problems?