How can I get meaningful function names in callgrind output on OSX from the command line?
Asked Answered
L

1

7

Goal: I would like to be able to analyze the output of callgrind (and later cachegrind too) and would like to see meaningful variable names when using the callgrind_annotate CLI.

Prior Research: I am aware of the dsym flag in Valgrind (http://valgrind.org/docs/manual/manual-core.html) and believe I have an understanding of how debug symbols work on osx (LLDB not showing source code). The handful of mentions of this issue I've seen on this site either went unanswered or were cases where the -g flag wasn't included.

Theory(May be wrong...): Based on the "dym=" line in valgrind output I'm wondering if valgrind is struggling to find the path for the dsym directory."

What data can I give you?

Given the following source code:

#include <iostream>
#include <cmath>
bool isPrime(int x)
{
        int limit = std::sqrt(x);
        for (int i = 2; i <= limit; ++i)
        {
                if (x % i == 0)
                {
                        return false;
                }
        }
        return true;
}
int main()
{
        int primeCount = 0;
        for (int i = 0; i < 1000000; ++i)
        {
                if (isPrime(i))
                {
                        ++primeCount;
                }
        }
}

The following command line instructions were used:

g++ -g -c badprime.cpp
g++ badprime.o -o badprime
nm -pa badprime
dsymutil badprime
valgrind --tool=callgrind --dsymutil=yes ./badprime
callgrind_annotate --auto=yes callgrind.out.45056 badprime.cpp

The nm -pa bit was to ensure that the debugging map information was present. I also ran dwarfdump on the dSYM folder to ensure that debugging info was present. I am greeted with the line " No information has been collected for badprime.cpp" as the output of the annotate command.

Compiler information:

Apple LLVM version 8.0.0 (clang-800.0.42.1) 
Target: x86_64-apple-darwin15.6.0

Valgrind information:

valgrind-3.11.0

Initial verbose output from valgrind:

$ valgrind --tool=callgrind --dsymutil=yes -v ./badprime
==45056== Callgrind, a call-graph generating cache profiler
==45056== Copyright (C) 2002-2015, and GNU GPL'd, by Josef Weidendorfer et al.
==45056== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==45056== Command: ./badprime
==45056==
--45056-- Valgrind options:
--45056--    --tool=callgrind
--45056--    --dsymutil=yes
--45056--    -v
--45056-- Output from sysctl({CTL_KERN,KERN_VERSION}):
--45056--   Darwin Kernel Version 15.6.0: Thu Jun 23 18:25:34 PDT 2016; root:xnu-3248.60.10~1/RELEASE_X86_64
--45056-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi
--45056-- Page sizes: currently 4096, max supported 4096
--45056-- Valgrind library directory: /usr/local/Cellar/valgrind/3.11.0/lib/valgrind
==45056== For interactive control, run 'callgrind_control -h'.
--45056-- /usr/lib/dyld (rx at 0x7fff5fc00000, rw at 0x7fff5fc38000)
--45056--    reading syms   from primary file (6 1229)
--45056-- Scheduler: using generic scheduler lock implementation.
==45056== embedded gdbserver: reading from /var/folders/7h/d91hqksj7bdfxp0km10b2qn40000gp/T//vgdb-pipe-from-vgdb-to-45056-by-dudett-on-???
==45056== embedded gdbserver: writing to   /var/folders/7h/d91hqksj7bdfxp0km10b2qn40000gp/T//vgdb-pipe-to-vgdb-from-45056-by-dudett-on-???
==45056== embedded gdbserver: shared mem   /var/folders/7h/d91hqksj7bdfxp0km10b2qn40000gp/T//vgdb-pipe-shared-mem-vgdb-45056-by-dudett-on-???
==45056==
==45056== TO CONTROL THIS PROCESS USING vgdb (which you probably
==45056== don't want to do, unless you know exactly what you're doing,
==45056== or are doing some strange experiment):
==45056==   /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/../../bin/vgdb --pid=45056 ...command...
==45056==
==45056== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==45056==   /path/to/gdb ./badprime
==45056== and then give GDB the following command
==45056==   target remote | /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/../../bin/vgdb --pid=45056
==45056== --pid is optional if only one valgrind process is running
==45056==
--45056-- /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_core-amd64-darwin.so (rx at 0x100002000, rw at 0x100004000)
--45056--    reading syms   from primary file (3 21)
--45056--    dSYM= /usr/local/Cellar/valgrind/3.11.0/lib/valgrind/vgpreload_core-amd64-darwin.so.dSYM/Contents/Resources/DWARF/vgpreload_core-amd64-darwin.so

callgrind_annotate output:

--------------------------------------------------------------------------------
Profile data file 'callgrind.out.45056' (creator: callgrind-3.11.0)
--------------------------------------------------------------------------------
I1 cache:
D1 cache:
LL cache:
Timerange: Basic block 0 - 278668477
Trigger: Program termination
Profiled target:  ./badprime (PID 45056, part 1)
Events recorded:  Ir
Events shown:     Ir
Event sort order: Ir
Thresholds:       99
Include dirs:
User annotated:   badprime.cpp
Auto-annotation:  on

--------------------------------------------------------------------------------
         Ir
--------------------------------------------------------------------------------
913,332,521  PROGRAM TOTALS

--------------------------------------------------------------------------------
         Ir  file:function
--------------------------------------------------------------------------------
893,174,739  ???:0x0000000100000ee0 [???]
 12,157,012  ???:0x0000000100000f50 [???]

--------------------------------------------------------------------------------
-- User-annotated source: badprime.cpp
--------------------------------------------------------------------------------
  No information has been collected for badprime.cpp

I'd be super grateful to whatever help could be provided.

Letsou answered 20/11, 2016 at 12:21 Comment(0)
B
5

Check your linker (ld) command line options. -s strips all symbol information and it takes precedence over -g in the compiler.

From ld manual:

-s
--strip-all
Omit all symbol information from the output file.

ftp link

I noticed that you don't use ld for linking. So this is not applicable to your problem. However, I will leave my answer here for people who use ld and experience this issue.

Bedard answered 16/3, 2017 at 5:18 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.