Software call graph to show "trace" from one function to another

Question

To help me understand large software projects, I'm looking for a program that reads Callgrind data (or another common and easily generated call-graph format) of software written in C, specifically so it can show me if and how one function is ultimately called by another, i.e. which functions lie "in between".

Basically like a call graph, except I give it two function names at the beginning and it should just show me if one of them appears in the other's call stack, as well as all the functions in between the two.

This is for software projects that are so large that simply exporting the entire call graph as a picture is unrealistic.

I know there is KCacheGrind for interactive visualization of Callgrind data, but it seems to have built-in limitations on what it is willing to show in a single graph, again in order to limit its size. For my purpose, however, the program wouldn't have to show any branching, just the "straight line" from one function to another (if it exists), so these kinds of limitations wouldn't be needed.

Answer 1

There is gprof2dot is a python which can process such output, without the size limitations, to produce a dot file that can then be converted to a graph using graphviz it can process the output of:

• Linux perf
• Valgrind's callgrind tool
• oprofile
• sysprof
• xperf
• VTune Amplifier XE
• Very Sleepy
• python profilers
• Java's HPROF
• prof, gprof

Example Output

Since it is going to be using python anyway you could probably use a little python to filter the graph to that between the functions that you are interested in or there are programs such as xdot.py, or its branches, and zgrviewer that allow zoomable display of the output.

You could also take a look at using doxygen's call and callers graphs - these will not handle any calls by function pointer, etc.

Optionally you could just put a stack dump/stack trace into the code at the beginning of function that you wish to produce the diagram for, this SO question discusses some options for doing that. Alternatively you could put a break point in under your debugger and then do a stack dump manually to get the information.

Answer 2

Why Callgrind doesn't work well

I ended up not using Callgrind for this after all, as it produced too many nodes that had nothing to do with the functions I was interested in and only appeared because they were called from cycles that contained intermediate functions.

For instance, let's say I'm interested in the relationship between A and C, but have call stacks such as:

A > B > C
X > B > Z > B

Then X and Z will appear in the graph produced with Callgrind even if a program such as gprof2dot is used which allows you to specify start and end points. Neither X nor Z are end points here, they're in a cycle, so they're not filtered out. I think the effort to remove this sort of garbage information from the graph far outweighs the effort I put into the solution I ended up using (see below).

My solution

So as per the suggestion at the end of Steve Barnes's answer, I used a debugger (gdb) to output stack traces and then processed them further. I wrote a small script to automate this, which can be found here.

The graphs thus produced are a lot smaller than the ones I got from Callgrind data. Here is one for determining the relationship between two GTK+ functions gtk_application_set_menubar and gtk_accel_label_set_accel:

In this case it turned out that there is no direct call relationship; they only share common callers (the terminal output from my script was more useful in determining this than the graph itself, though).