Does GDB support "run-time sampling" or is there a custom extension?

Question

Motivation: I can’t get google cpu profiler to work on the machine where the code works (with my last breath I curse libunwind :)), so I was wondering if gdb supports high-frequency random suspension of program execution, keeping the name of the function in which it occurred break, and counting how many times he paused function x. This is what I would call a "run-time sample", perhaps a more accurate / smarter name. I looked at oprofile, but it is difficult: a) to find out whether it can do b) to find out how to do this EDIT: apparently the correct name: "statistical sampling method"

EDIT2: the reason Im is offering generosity for this, I see some ppls on SO recommend doing a 10-20x manual break and parsing the stack with bt ... It seems very wasteful when it comes to time, so I want for some smart ppl to automate it. :)
EDIT3: gprof will not allow it ... I tried to run it recently in the ARM system, and the output was garbage ... :( I think its problems with multithreading are the reason for this ...

Answer 1

You can manually fetch to GDB by pausing it at run time.

It seems to you that you want gprof , but if your goal is to make the program as fast as possible, I would suggest

• A high sampling rate does not help.

• Counting the number of samples in which the program counter is in function X is not useful, except for artificially small programs.

If you follow this link, you will see the reasons and methods for successful execution.

Answer 2

GDB will not do it well, although you can certainly hack something that yields wildly inaccurate results.

I would suggest the Valgrind plugin "Callgrind". As a bonus, it does not require absolutely no recompilation or other special settings. All you need is a valgrind installed on your system and debugging information in your program (or full information about characters, at least I'm not sure).

Then you invoke your program as follows:

valgrind --tool=callgrind <your program command line> 

When this is done, the name of the file callgrind.out.<pid> will be indicated in the current directory. You can read and visualize this file with a very nice GUI tool called kcachegrind (usually you need to install it separately).

The only problem is that since callgrind slows down the execution of your program a little, the time spent on system calls may be less (in percentage terms) than it actually would be. By default, callgrind does not include system time in its counters, so the values ​​it gives you are a real comparison of the code in your program, if not the actual time "under" this function. This may be confusing at first, so if that happens try adding --collect-systime=yes .

I'm not sure what the state of callgrind on ARM might be. ARMv7 is listed as a supported platform , but only says “fully enough”, whatever that means.