www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/1999/04/20/07:32:46

X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Tue, 20 Apr 1999 11:50:55 +0200 (MET DST)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: djgpp-workers AT delorie DOT com
Subject: Re: Probblem: Debug info COFF vs. stabs
In-Reply-To: <199904191933.PAA30342@delorie.com>
Message-ID: <Pine.LNX.3.93.990420113730.7469A-100000@acp3bf>
MIME-Version: 1.0
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

[Robert: bei Bedarf k"onnen wir Details auch privat in Deutsch
abhandeln...]

On Mon, 19 Apr 1999, Robert Hoehne wrote:

> > It seems like the base address of any code offset addresses found in the
> > debug information (line numbers, esp.) is different for COFF and stabs.
[...]

> Do you have a real example for it? What gcc/binutils you are using?

All this is from memory, so caveat lector: In a nutshell, the example is
as simple as: run 'gprof -l' of binutils 2.8.1 on any program compiled and
linked with 'gcc -g -pg' (gcc-2.8.1, as distributed). You'll find that the
source line information displayed is completely wrong. Switching to 'gcc
-gstabs -pg' or 'gcc -ggdb -pg' makes it work. Use a really small program
to test this, 'gprof -l' is awfully slow, without any of the patches I
have made (or collected from the net). 

> > I'm unsure which of the three possible things is wrong, here:
> > 1) BFD's understanding of COFF 
> > 2) DJGPP's understanding of COFF
> > 3) BFD's understanding of stabs symbols
> 
> I can't imagine any of the above, since other programs using BFD
> work correct (like gdb) 

But we do have our own variant of COFF (the coff-go32 target), after all.
So maybe some minor difference of our own variant of COFF is not taken
account for in BFD? 

SET hinted that you may have had similar problems with symbol-reading for
gdb, as well. Is that so? And if so: what kind of problems?

> 4) GROF's handling of BFD to read the symbols?

It's a bit difficult to disentangle this, due to the almost complete lack
of any real documentation for the 'bfd_find_nearest_line()' function(s).
Without knowing what exactly it's supposed to do, it's close to impossible
to find out whether that function is implemented incorrectly, or used
incorrectly by gprof.

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