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 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk [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.