OSX doesn't have objdump, add otool support.
GoogleCodeExporter opened this issue · comments
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
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
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
- Changed state: NotABug
- Added labels: Priority-Medium, Type-Defect
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
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