ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have used gprof to generat the time elapsed in each of the function in my little program. But the time elapsed in system API have not been calculated, like open, read, close, memset, etc.
I am wondering how to enable gprof to calculate time elapsed in system API?
The only thing you can do is write wrapper functions for each of the system calls in which you're interested.
For example, if you're interested in including all your read() calls, write a wrapper function Read() with the same type as read() and whose parameters have the same type as the parameters for read(). Have Read() call read() and return the value that read() does. Then replace all your calls to read() (except the one in Read()) with calls to Read().
There are other reasons for writing wrapper functions for system calls. These reasons concern maintainability of your program. For example, if you later want to come back to your program and do something special for error recovery for all open() calls in your program, you can put that error recovery in just one place: your Open() function. It's also good for debugging, if you want to place a breakpoint (or do a debugging display of data) for every open() call, for example.
Last edited by wjevans_7d1@yahoo.co; 02-13-2007 at 05:32 AM.
The only thing you can do is write wrapper functions for each of the system calls in which you're interested.
For example, if you're interested in including all your read() calls, write a wrapper function Read() with the same type as read() and whose parameters have the same type as the parameters for read(). Have Read() call read() and return the value that read() does. Then replace all your calls to read() (except the one in Read()) with calls to Read().
There are other reasons for writing wrapper functions for system calls. These reasons concern maintainability of your program. For example, if you later want to come back to your program and do something special for error recovery for all open() calls in your program, you can put that error recovery in just one place: your Open() function. It's also good for debugging, if you want to place a breakpoint (or do a debugging display of data) for every open() call, for example.
I have found that the total time reported on the flat profile is not equal to the whole run time of the program, is it because that the elapsed time in system API is not considered in the report of gprof flat profile?
(I calculate roughly in this way, the top function consumes 10 seconds, and it takes 10% of total time as displayed in gprof report, so the total time in gprof should be 100 seconds. But I have manually calculated that the whole time should be roughly 200 seconds.)
Currently, why I use gprof is because I need to run it for various machines (x86 and other architecture). I am not sure whether the tool you introduced has the capability.
Anyway, could you answer my original question please?
my original question,
--------------------
I have found that the total time reported on the flat profile is not equal to the whole run time of the program, is it because that the elapsed time in system API is not considered in the report of gprof flat profile?
(I calculate roughly in this way, the top function consumes 10 seconds, and it takes 10% of total time as displayed in gprof report, so the total time in gprof should be 100 seconds. But I have manually calculated that the whole time should be roughly 200 seconds.)
--------------------
gprof will only give you profiling for routines built to include the profiling code. Since you'll be linking to libraries which are not compiled with the profiling code, you won't see stats for functions in those libraries (unless you built them yourself and turned profiling on).
I'm not certain, but I suspect you'd need to use another mechanism to profile kernel routines.
oprofile uses a different mechanism to extract profiling data.
Last edited by matthewg42; 02-13-2007 at 07:37 AM.
I will use cross compile tool (for example, Monta Vista Linux) to compile my program, and run it on various H/W. I want to profile the time elapsed on each real H/W (other than the machine I compile/link my program) for my program. I am not sure whether oprofile could meet with my requirement.
Quote:
Originally Posted by matthewg42
gprof will only give you profiling for routines built to include the profiling code. Since you'll be linking to libraries which are not compiled with the profiling code, you won't see stats for functions in those libraries (unless you built them yourself and turned profiling on).
I'm not certain, but I suspect you'd need to use another mechanism to profile kernel routines.
oprofile uses a different mechanism to extract profiling data.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.