Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

gprof command line arguments to profiled program ?

4,056 views
Skip to first unread message

g f

unread,
Jan 4, 2008, 9:56:45 PM1/4/08
to
with gprof (on solaris 10 64 bit) is it possible to profile a program with
command line arguments like :

"gprof ./program -h" gives me the usage of gprof but the -h switch was meant
to program, not to gprof

all the usage examples I found seem to indicate argument less programs to
profile

Richard B. Gilbert

unread,
Jan 4, 2008, 10:33:48 PM1/4/08
to

Perhaps if you put the quotes around "./program -h"??

The man page is typically unhelpful about invoking gprof to profile a
program that takes command line arguments of its own. . . .

guen...@gmail.com

unread,
Jan 5, 2008, 12:01:10 AM1/5/08
to
On Jan 4, 7:56 pm, "g f" <gfan...@tiscalinet.it> wrote:
> with gprof (on solaris 10 64 bit) is it possible to profile a program with
> command line arguments like :
>
> "gprof ./program -h" gives me the usage of gprof but the -h switch
> was meant to program, not to gprof

To profile a program with gprof, you do the following:
1) compile and link the program with the -pg option to the compiler
2) run the program with whatever arguments and options you want,
letting it run until it exits normally. The gmon.out file will
be
generated when the program exits.
3) run gprof, passing it the path to the program and the path to the
gmon.out file (those default to "./a.out" and "./gmon.out",
respectively)

When you say "gprof ./program" you are *not* running the program. You
must have already run the program before you run gprof. You give
gprof the path to the program so that it can examine the debugging
information in the program itself in order to analyze the information
in the gmon.out file.


Philip Guenther

Ian Collins

unread,
Jan 5, 2008, 12:24:50 AM1/5/08
to
Can you build the application with Sun Studio and use the Studio profiler?

--
Ian Collins.

guen...@gmail.com

unread,
Jan 5, 2008, 12:27:53 AM1/5/08
to
On Jan 4, 7:56 pm, "g f" <gfan...@tiscalinet.it> wrote:
> with gprof (on solaris 10 64 bit) is it possible to profile a program with
> command line arguments like :
>
> "gprof ./program -h" gives me the usage of gprof but the -h switch
> was meant to program, not to gprof

To profile a program with gprof, you do the following:

g f

unread,
Jan 5, 2008, 8:16:20 AM1/5/08
to
when I run ./program -h it generates gmon.out, a binary not human readable
file, of it's own, because I gave the compiler cc and linker the flags -xpg
and eliminated /usr/lib library path and used the profiling c libraries and
so how it's linked it generates gmon.out
my impression is that somewhere in the gmon.out there is encoded the exact
command line with which I executed it i.e. "./program -h"
and when I run gprof "./program -h" I am really telling him not to execute
it but to look inside gmon.out to see what he can find regarding a certain
"./program -h" whereas he understands only the first argument $0 and looks
up "./program" and interprets "-h" as $1 and then gives me usage of gprof
I need to understand why when the program is executed without arguments
gprof reads out gmon.out without problems, whereas when the program is
executed with arguments it is not sufficient to tell gprof to read gmon.out
just with $0
for example when you execute debugger giving him a core file there is no
qualms about image name that generated the core in my understanding
also when you do "ps" to see processes the command line may sometimes appear
slightly different to what you typed originally, I wonder if inside the
gmon.out there is some sort of name mangling regarding the arguments to the
program maybe I have to do like gprof ./program_-h or some mangled notation
thanks for any usage examples with arguments which are obviously variable
number of arguments and I'm sure from gprof source code that it deals with
variable number of arguments

"g f" <gfa...@tiscalinet.it> wrote in message news:flmrls$lmj$1...@aioe.org...

g f

unread,
Jan 5, 2008, 11:40:32 AM1/5/08
to
looking at the source of gprof on another os darwin for example :
http://www.opensource.apple.com/darwinsource/10.4.8.ppc/cxxfilt-1/src/gprof/gprof.c
it seems to firstly parse the arguments recognised as gprof options with
while ((ch = getopt_long (argc, argv,
"aA::bBcCd::De:E:f:F:hiI:J::k:lLm:n::N::O:p::P::q::Q::st:Tvw:xyzZ::",
long_options, 0))

then it proceeds to obtain the image name from which to extract its symbols

if (optind < argc)
a_out_name = argv[optind++];

if there is an argument optind following the last recognised option, the
default image name should be a.out, my impression is that here there should
indeed be no arguments passed to gprof, because he is only interested in the
image filename from where to get the symbols, so this explains the absence
in any usage examples of arguments to the image, it makes sense to type only
"gprof a.out"

then it allows for a different named gmon.out if there is one specified,
like "gprof a.out mygmon.out":
if (optind < argc)
gmon_name = argv[optind++];

I think that the question is really when gprof tries to find the symbols
found in gmon.out in the symbols loaded from the image, the correlation
seems to fail perhaps because in gmon.out the symbols are somehow mangled by
the options passed to the image when it ran and created gmon.out
i.e. when I type "program -a0 -b0 -c0" it inserted the options "-a0 -b0 -c0"
into gmon.out which is binary and not immediate to see if and how they alter
the information in gmon.out

thanks for any ideas whatsoever

"g f" <gfa...@tiscalinet.it> wrote in message news:flnvvk$mcf$1...@aioe.org...

guen...@gmail.com

unread,
Jan 6, 2008, 12:17:00 AM1/6/08
to
On Jan 5, 9:40 am, "g f" <gfan...@tiscalinet.it> wrote:
> if there is an argument optind following the last recognised option,
> the default image name should be a.out, my impression is that
> here there should indeed be no arguments passed to gprof,
> because he is only interested in the image filename from where
> to get the symbols, so this explains the absence in any usage
> examples of arguments to the image, it makes sense to type only
> "gprof a.out"

Right. In your case, just type
gprof ./program

gprof doesn't care what options or arguments the program was run with.


> I think that the question is really when gprof tries to find the
> symbols found in gmon.out in the symbols loaded from the
> image, the correlation seems to fail perhaps because in
> gmon.out the symbols are somehow mangled by the options
> passed to the image when it ran and created gmon.out

That is not the case on any of the systems that I am aware of.


> i.e. when I type "program -a0 -b0 -c0" it inserted the options
> "-a0 -b0 -c0" into gmon.out which is binary and not immediate
> to see if and how they alter the information in gmon.out

Are you saying that gprof fails to work and instead reports an error
when you do this:
./program -h
gprof ./program

? If so, what's the error message?

Off hand, the only reason I can see for the above to fail would be if
the program does not call 'exit()' when run with the -h option. You
can only use gprof when the program exited by calling exit(). If it
calls exec(), or abort(), or _exit(), or dies from a signal then the
complete profiling information will *not* be written out.


Philip Guenther

0 new messages