This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: How do I get a profiled libstdc++?
- From: Scott A Crosby <scrosby at cs dot rice dot edu>
- To: libstdc++ at gcc dot gnu dot org
- Date: Thu, 23 Nov 2006 10:21:37 -0600
- Subject: Re: How do I get a profiled libstdc++?
- References: <oydejrxjulx.fsf@cs.rice.edu>
On Mon, 20 Nov 2006 22:23:38 -0600, Scott A Crosby <scrosby@cs.rice.edu> writes:
> | > I've been trying to profile a program which has a substantual
> | > amount
> | > of its runtime in libstdc++. But try as I might, I can't get a copy of
> | > libstdc++ to compile with profiling, get my program to link against
> | > it, and have it generate a gmon.out that has frequency counts for the
> | > code in libstdc++. It only partially works, generating call counts for
> | > my program and the template functions in stdc++ that my program
> | > invokes.
|
> | to compile libstdc++ with profiling, you can do:
|
> | make CXXFLAGS="-pg" all
|
> | in the libstdc++ build directory.
Did this, the build system complained a bit. FYI: the compiler
complained about -fSOMETHING-sections being incompatible with -pg.
> and be sure you build only static arechive (the fun part, double
> check the result of the build) and link only statically.
This works! Just a -static!
> | When you say "only partially works," what other info were you expecting?
>
I got call counts for all template functions in the stdc++ header
files, but no counts for functions in compiled into libstdc++.
> The shared library did not "work" for me, when I tried with gcjx: the
> profiler, for some reasons, cannot account for shared objects
> properly. It would report the amont of time spend in crossing the
> DSO boundaries, but it would not report on the time spent doing libstdc++
> jobs.
I guess I was tripped up in trying to profile with a dynamic
libstdc++. And my attempts to compile statically against libstdc++ and
dynamically against all other libraries weren't working.
Thanks for the tip.
Also, the reason I'm using gprof instead of oprofile is that oprofile
is great at figuring out what functions or parts of a function are a
problem. gprof is much better at figuring out which sections of a
program have a problem. Eg. Boost's lexical_cast<> is responsible for
~5% of this program's runtime, but the entire >30 function call tree
invoked by lexical_cast<> --- including locale, string, and iostream
processing accounts for 45% of the runtime. Even though I love
oprofile, I could have only learned this from oprofile with
difficulty.
Thanks everyone!
Scott