From:	broeker AT acp3bf DOT knirsch DOT de (Hans-Bernhard Broeker)
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Profiler
Date:	9 Jul 1999 15:59:55 +0200
Organization:	RWTH Aachen, III. physikalisches Institut B
Lines:	29
Message-ID:	<7m4v8r$55g@acp3bf.knirsch.de>
References:	<7m33mj$ojc$1 AT reader1 DOT wxs DOT nl>
NNTP-Posting-Host:	acp3bf.physik.rwth-aachen.de
X-Newsreader:	TIN [version 1.2 PL2]
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

Bas Hamstra (bas DOT hamstra AT wxs DOT nl) wrote:
> Also: is there a possibility for source line profiling in DJGPP?

In principle, there is 'gprof -l'. But with DJGPP, you have to pay
attention to some details to get it working.

1) You have to use '-gstabs' or '-ggdb' debugging information (and a
gcc built to support that).

2) You may have to fix the 2.02 profiling bug in your libc, or revert
to 2.01.

3) -- a showstopper, for now -- you have to find and fix a few bugs and
efficiency problems in gprof and the underlying BFD library.

On my machine at home, I do have a fixed version of gprof that allows
line-by-line profiling, but I (still) haven't found the time and will
to package up the changes and get them back to the FSF, partly because
not all of them are exactly my own...

For full usability, you also need the info gathered by basic block
profiling ('gcc -a', in addition to the '-pg' timing and call
frequency data), in a format usable by gprof, instead of the
human-readable text normally found in 'bb.out' after running a 'gcc
-a' compiled program. This in turn requires changes to the gcc
(libgcc.a, to be precise) source.
-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -