Line number in Google Perftools CPU profiler on MacOSX

Question

I am trying to profile some C++ programs on MacOSX. So I built google-perftools, wrote a program, compiled using MacPorts g++ 4.7, with -g compiler flag, and linked to libprofiler. Then I ran:

CPUPROFILE=cpu.profile ./a.out

Then I ran pprof to generate the output:

[hidden ~]$ pprof --text ./a.out cpu.profile 
Using local file ./a.out.
Using local file cpu.profile.
Removing __sigtramp from all stack traces.
Total: 282 samples
     107  37.9%  37.9%      107  37.9% 0x000000010d72229e
      16   5.7%  43.6%       16   5.7% 0x000000010d721a5f
      12   4.3%  47.9%       12   4.3% 0x000000010d721de8
      11   3.9%  51.8%       11   3.9% 0x000000010d721a4e
       9   3.2%  55.0%        9   3.2% 0x000000010d721e13
       8   2.8%  57.8%        8   2.8% 0x000000010d721a64
       7   2.5%  60.3%        7   2.5% 0x000000010d7222f0
       6   2.1%  62.4%        6   2.1% 0x000000010d721a4c
       6   2.1%  64.5%        6   2.1% 0x000000010d721b1f
       6   2.1%  66.7%        6   2.1% 0x000000010d721e0c
       5   1.8%  68.4%        5   1.8% 0x000000010d721fba
    ......

It looks like the perftools don't convert the addresses to function names.

Does anyone know what I am missing here? What should I do to let the profiler generate the correct result.

EDIT: More information: it is not a problem of pprof or google-perftools, but more something like gcc or macosx, because Instrument.app also shows addresses instead of line numbers. I am not familiar with how debug symbols work under Mac OS X, so I would rather think it as my missing something here, instead of being bugs in gcc or Mac OS X. I wonder whether anyone can provide some hints on how debug info works for Mac OS X.

Answer 1

This seems to be related to the address space layout randomization (ASLR) introduced in OS X 10.5

I've filed issue #562 on the gperftools issue tracker. You can disable ASLR by passing -Wl,-no_pie.

Also, if you're not bound to use gperftools, Instruments (comes with Xcode) is worth a try.

Answer 2

I believe in this platform the debug symbols stay in the .o file(s), they are not moved to the executable. To get symbols in gdb or profilers you need to save the .o files. This may mean that you need to compile your application in two steps (compile, then link) to preserve the .o files.

See this question for additional information.

In looking at the pprof Perl source code, symbol names are obtained via the use of nm and c++filt, so you could try to run those standalone and figure out why they don't work. From the pprof source it looks like it tries a bunch of different command line arguments to cover several versions of nm. This is a summary of the ways

nm [-D] -n [-f] [--demangle] object-file 2>/dev/nul [| cpp+filt]

The parts that I put in brackets are those that the script determines at runtime if are required for your platform and versions of nm and c++filt. Try all the combinations of the above and see what works. Then look at what the pprof script does, maybe by adding some printfs to it.

Good luck.