delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1999/07/21/07:15:08

X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Wed, 21 Jul 1999 13:13:58 +0200 (MET DST)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp AT delorie DOT com
Subject: Re: Bizarre debugging format problem
In-Reply-To: <Pine.SUN.3.91.990721105028.7757C-100000@is>
Message-ID: <Pine.LNX.3.93.990721130409.202B-100000@acp3bf>
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, Eli Zaretskii wrote:

> 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.  

Not totally. It just assumes the wrong 'base' address to translate the
offsets found in the symbols to code addresses and vice versa. This base
is different for COFF and stabs debug info, which is why you can 'fix' it
by using '-gstabs'. 

I once managed to fix that by adding a constant to the argument of the
find_nearest_line call. Regrettably, I seem to have lost that patch,
otherwise, I'd have sent it to djgpp-workers for discussion, already.

[...]
> 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.

I've always wondered how on earth GDB manages to get this right,
given that the BFD function is clearly buggy. 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.
I'll have to look into gdb sources as well, then...

> > 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?

I hope they will. I just have to re-discover what that 'magical' offset
was, and re-insert it into coff_find_nearest_line(), but after the call to
stabs_find_nearest_line() made by it. That's not the only change, though. 
There are also some others, needed for performance improvement in both the
stabs and the COFF case, by caching results. That's needed to avoid having
to search the whole list of debug entries for each code address.

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019