casseopea2 / gperftools

Automatically exported from code.google.com/p/gperftools
BSD 3-Clause "New" or "Revised" License
1 stars 0 forks source link

OSX doesn't have objdump, add otool support. #149

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Compile something with a shared library.
2. Run with profiling enabled.
3. Run pprof.

What is the expected output? What do you see instead?
pprof fails because OSX does not have objdump.  It uses, I believe, otool
instead.  

What version of the product are you using? On what operating system?
OS X 10.5.9, G++ 4.0.1

Please provide any additional information below.
My exact error is:

pprof /usr/local/bin/jags jags.prof Can't exec "objdump": 
No such file or directory at /usr/local/bin/pprof line 2833.

objdump /System/Library/Frameworks/Accelerate.framework/Versions/A/
Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib: No such file or
directory

Original issue reported on code.google.com by trist...@gmail.com on 21 Jun 2009 at 7:05

GoogleCodeExporter commented 9 years ago
This is actually happening because jags is a bourne shell script, which calls 
lots of
profilable code.  The file_type in ConfigureObjTools doesn't detect that the OS 
is
OSX.  A brute force fix is just taking (line 3402)

$obj_tool_map{"otool"} = "otool";

outside the if statement.  The ultimate solution is to detect the type 
differently.

Original comment by trist...@gmail.com on 21 Jun 2009 at 7:34

GoogleCodeExporter commented 9 years ago
You can only profile executables, not shell scripts.  I'm not sure what command 
you
ran to create the profile (jags.pprof), but it's only going to be the profile 
from
one executable that your shell script wrote (probably the last one).  You could 
run
pprof on that last executable, or change your shell script to set CPUPROFILE (or
whatever envvar is appropriate for you) to a different value for each 
executable you
run, and then call pprof on each executable separately.

When you do your brute-force fix, and run pprof, what happens?  I would expect 
otool
to give no output, but I admit I don't really know the tool.

Original comment by csilv...@gmail.com on 21 Jun 2009 at 7:39

GoogleCodeExporter commented 9 years ago
The shell script just sets lots of other environmental variables, so you are 
right,
all I need to do is call the pprof command using the actual executable I called
within the shell script.

There remains one bug though.  OSX does not have addr2line.  I believe "atos" 
is the
OSX equivalent.  After running pprof the first four lines of output are:

sh: addr2line: command not found
sh: addr2line: command not found
sh: addr2line: command not found
sh: addr2line: command not found

Most of the top20 output looks okay, but there are a fair amount of addresses:

      69  14.3%  14.3%      241  49.8% LogicalNode::deterministicSample
      50  10.3%  24.6%       54  11.2% ScalarFunc::checkParameterValue
      44   9.1%  33.7%       44   9.1% Node::value
      42   8.7%  42.4%      123  25.4% ScalarFunc::evaluate
      22   4.5%  46.9%      270  55.8% Sampler::setValue
      20   4.1%  51.0%       20   4.1% 0x0003eb3c
      19   3.9%  55.0%       19   3.9% 0x0003eb12
      13   2.7%  57.6%       13   2.7% 0x00173fff
      13   2.7%  60.3%       13   2.7% 0x00185200
      12   2.5%  62.8%       12   2.5% ScalarFunc::checkScalarValue
      10   2.1%  64.9%       10   2.1% 0x00172209
       7   1.4%  66.3%        7   1.4% Node::parents
       7   1.4%  67.8%        7   1.4% 0x00174003
       6   1.2%  69.0%        6   1.2% 0x0018520f
       6   1.2%  70.2%        6   1.2% 0x00173fd9
       6   1.2%  71.5%        6   1.2% 0x0003eb1e
       5   1.0%  72.5%        7   1.4% 0x00173f79
       5   1.0%  73.6%        5   1.0% _write$NOCANCEL$UNIX2003
       5   1.0%  74.6%        5   1.0% _writev$UNIX2003
       4   0.8%  75.4%        4   0.8% 0x0003ffc1
       4   0.8%  76.2%        4   0.8% 0x0003ffc7

Original comment by trist...@gmail.com on 21 Jun 2009 at 8:07

GoogleCodeExporter commented 9 years ago
It looks like atos just does the symbol to function mapping (what we're doing
manually via otool) -- it doesn't show line numbers.  If it does, I didn't see 
a flag
to do so.  Can you give an example usage?

The addresses in your function are probably from libc, or some other library 
that
doesn't have debug symbols.  I don't think it's possible to turn those into 
function
names, in general.

Original comment by csilv...@gmail.com on 22 Jun 2009 at 4:08