How to the prof/gprof tool

Hello everyone

I want to use the standard Unix prof/gprof tool for my application but I cannot get through the compilation part. I have add the -xpg option in my makefile as specified in the cc man page but the linker gives me the following error:
***************************************
Undefined first referenced
symbol in file
mcount dlmMain.o
ld: fatal: Symbol referencing errors. No output written to dlm
*** Error code 1
make: Fatal error: Command failed for target `DLM'
******************************************

My main module does not contain any mcount symbol, so I guess is something that has to do with the prof option (-xpg).

How I can overcome this problem? Is there any site with usefull info?

Thanx

I don't know what the -x option does, it's not an option I've ever seen, that I can recall.

Normally -pg does:

  1. inserts the names of all of the symbols into the output file (image file)
  2. add monitor code (see monitor.h)
  3. links the image statically - that is, it puts all of the code into the image file instead of having the code open libraries at run time. Called a static link.

First off try it without the "x". If that fails, then you may be missing the usr/lib/libc.a file - the one used to link statically. If you can see the file and you are using gcc (gprof) then check for the existence of the file: /usr/lib/libgprof32.* <- this assumes you are not on Linux.

Thanx Jim. It worked with the -pg.

Can anybody suggest a site with Profiling info or Perfromance Analysis/Evaluation tools?

Thanx again.

FWIW - you should profile and mess with your code ONLY AFTER:

  1. Code works perfectly correctly and meets all requirements.
  2. It has been clearly identified that your code runs too long. And that the business, not your self-image, will profit from the time you spend to speed it up.

In realtime systems performance tuning is a given part of the requirements.

Examples of #2:
You write a report that runs in 40 minutes. The user starts the report, goes to lunch,
comes back reads the report. You decide to tune it, and get it down to 25 minutes of runtime. The user will still start the report and then go to lunch. You have acheived nothing. This is not what you want to tune.

You have a routine that displays input as the user types. It has a runtime of two seconds. The user has to type, wait, type ,wait. You tune it so that it runs in .25 seconds. Now the user sees improvement.

You have long batch runs that go overnight and sometimes bump into the time when users log on again the next day. If there are any delays, then users are asked not to log in. This is a case where tuning is almost mandatory.

Runtimes can also be affected by the amount of free space on the disk system and the number of processes running.

Are you not able to interpret the output from prof? Generally this kind of tuning is more art than science.