"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
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. . . .
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.
To profile a program with gprof, you do the following:
"g f" <gfa...@tiscalinet.it> wrote in message news:flmrls$lmj$1...@aioe.org...
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...
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