2

I am using Intel VTune Amplifier XE 2011 to analyze the performance of my program. I want to be able to view the source code in the analysis results, and the documentation says I need to provide the symbol information. Unfortunately, it does not state how to generate that symbol information when compiling my program. In the Windows version of VTune all I had to do was provide the ".pdb" file that Microsoft Visual Studio would generate. Is there a similar kind of file I can create using g++ to provide this symbol information?

Dylan Klomparens
  • 2,853
  • 7
  • 35
  • 52

3 Answers3

3

Have you tried compiling with -g ? Normally that is all you need to generate symbolic data for debuggers, profilers, etc.

Incidentally, for profiling on Linux, Zoom from RotateRight.com is a lot more user-friendly than VTune. (UPDATE: Zoom is unfortunately no longer supported. Use perf for simple profiling.)

Paul R
  • 208,748
  • 37
  • 389
  • 560
2

The most "classic" way to get an executable to contain the debug information with GCC is to specify the "-g" command line option as mentioned by the other posters. This does not incur any performance hit since debug information resides in ELF sections which are not part of the code or data segment. That is, the .debug* sections are not mapped into the memory during normal program execution, it's only the debug time when the debugger gets them in.

Another useful consideration for any developer working on production software is to use separate debug information files. That assumes compiling the program with "-g" as described above and then using objcopy utility to copy out the ELF sections containing debug information into a separate file and adding a link from the original binary file to the separate debug information file. This is extremely useful for being able to store the debug information for the bits you released to a customer so that post-mortem debugging is possible. And of course, for performance profiling on the release bits, too.

Alexey Alexandrov
  • 2,951
  • 1
  • 24
  • 24
1

gcc -g <your stuff> should be all that's necessary. However I used an older version.

The command line options for the newer stuff is here

EDIT: This SO answer is probably more valuable than anything here.

Community
  • 1
  • 1
JimR
  • 15,513
  • 2
  • 20
  • 26
  • Yes, but will this slow the execution of the program? – Dylan Klomparens Jan 14 '11 at 21:46
  • Nope - it just makes the executable a little larger. – Paul R Jan 14 '11 at 21:47
  • Profiling almost always does. The more info you allow the profiler to collect the slower it will be. -g should not have much effect. – JimR Jan 14 '11 at 21:48
  • @JimR: I assumed he was asking whether compiling with -g made the program run slower, which of course it doesn't. – Paul R Jan 14 '11 at 21:50
  • Excellent, I will compile with the -g option. – Dylan Klomparens Jan 14 '11 at 21:53
  • @Paul R: Agreed. I made what is probably the wrong assumption when I answered. People are often surprised at how slow a profiler runs. – JimR Jan 14 '11 at 21:58
  • 1
    @JimR: this is mainly a problem with instrumented profiles, like gprof et al. Sampling profilers like Zoom, Shark, etc tend to have only a small impact on performance, unless you set the sampling interval to a very low value (e.g. < 1 ms). – Paul R Jan 15 '11 at 09:58
  • 1
    @JimR: There are twp things to understand about wall-clock time stack-sampling profilers. 1) Sample rates do not need to be high, because most of the information you get about where problems are in 10^4 samples is also contained in any 10^2 (or less) of those samples. 2) Even though taking a sample is "quick", it does not change the results very much if it is not quick, because it is reporting percents. I take samples manually, and it does not affect the percents. – Mike Dunlavey Jan 15 '11 at 15:03