bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gprof] strange behavior, esp spontaneous


From: Ross Boylan
Subject: [gprof] strange behavior, esp spontaneous
Date: Wed, 12 Jan 2005 23:47:29 -0800
User-agent: Mutt/1.5.6+20040907i

I have been profiling some code on 2 different systems.

On both, I see lots of <spontaneous> entries.  This puzzles me, since
the functions called "spontaneously" are actually called by other
functions in my program.  Some of them indicate very little time (and
no children) though I know most of the action happens below them.

On one system, Mac OSX, most of the <spontaneous> stuff seems to
concern memory allocation and deallocation, so it is likely happening
in the C++ run time or in system libraries.  I have set
DYLD_IMAGE_SUFFIX=_profile, but this doesn't seem to be picking out
special versions of some of the libraries.  For one thing, inspecting
the output with the -v option shows many of the libraries are being
captured as .o files.

So on the Mac is a double mystery: why are these calls being recorded
at all, and why aren't their parents recorded?

I though gprof worked with gcc instrumented code, and it would capture
the complete call stack for instrumented code and nothing for
non-instrumented code.  I am not sure how the time in non-instrumented
(usually low-level, in my case) code is treated: is it ignored, or
swept into the time of the lowest level instrumented call?

I originally got into this because the Mac showed substantial time in
the spontaneous calls.  The other system (linux) shows spontaneous
calls as well (that is, other than the top-level), but they don't have
significant time.

I'm using Debian GNU/Linux, mostly testing. 
binutils 2.15-5 
g++-3.3        3.3.5-5

I am still trying to pin down the exact versions of the toolchain on
OSX, but it is g++ 3.3 there as well.
$ g++ --version
g++ (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666)

The program is in C++, and I am linking with libtool.  It is possible
it is not handling -pg properly,  On Linux, it is not passed to the
linker:
../libtool --mode=link g++ -v -o profile -g -pg profile.o 
ConstrainedCoefficients.o Data.o Covariates.o Evaluator.o Specification.o 
Model.o Path.o PathGene\
rator.o SimpleRecorder.o SuccessorGenerator.o StateTimeClassifier.o 
TestRecorder.o AbstractTimeStepsGenerator.o FixedTimeStepsGenerator.o 
CompressedTimeSte\
psGenerator.o TimeStepsGenerator.o TestManager.o mspath.o Manager.o Rstub.o -pg
g++ -v -o profile -g -pg profile.o ConstrainedCoefficients.o Data.o 
Covariates.o Evaluator.o Specification.o Model.o Path.o PathGenerator.o 
SimpleRecorder.\
o SuccessorGenerator.o StateTimeClassifier.o TestRecorder.o 
AbstractTimeStepsGenerator.o FixedTimeStepsGenerator.o 
CompressedTimeStepsGenerator.o TimeSteps\
Generator.o TestManager.o mspath.o Manager.o Rstub.o -pg
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.5/specs
Configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/\
info --with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared 
--with-system-zlib --enable-nls --without-included-gettext 
--enable-__cxa_atexit --enable-\
clocale=gnu --enable-debug --enable-java-gc=boehm --enable-java-awt=xlib 
--enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.5 (Debian 1:3.3.5-5)
 /usr/lib/gcc-lib/i486-linux/3.3.5/collect2 --eh-frame-hdr -m elf_i386 
-dynamic-linker /lib/ld-linux.so.2 -o profile 
/usr/lib/gcc-lib/i486-linux/3.3.5/../.\
./../gcrt1.o /usr/lib/gcc-lib/i486-linux/3.3.5/../../../crti.o 
/usr/lib/gcc-lib/i486-linux/3.3.5/crtbegin.o 
-L/usr/lib/gcc-lib/i486-linux/3.3.5 -L/usr/lib/\
gcc-lib/i486-linux/3.3.5/../../.. profile.o ConstrainedCoefficients.o Data.o 
Covariates.o Evaluator.o Specification.o Model.o Path.o PathGenerator.o Simple\
Recorder.o SuccessorGenerator.o StateTimeClassifier.o TestRecorder.o 
AbstractTimeStepsGenerator.o FixedTimeStepsGenerator.o 
CompressedTimeStepsGenerator.o \
TimeStepsGenerator.o TestManager.o mspath.o Manager.o Rstub.o -lstdc++ -lm 
-lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc-lib/i486-linux/3.3.5/crtend.o 
/usr/\
lib/gcc-lib/i486-linux/3.3.5/../../../crtn.o

Can anyone shed any light on these behaviors?

Thanks.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]