Extracting call graphs (Re: Show functions in obj files?)

rfg@monkeys.com (Ronald F. Guilmette) wrote:
> Dietmar Schroeder <schroeder@ifn.ing.tu-bs.de> wrote:
> >we are looking for a tool that could display all functions used in a
> >c-program by examinating the gcc compiled obj files (inc. debug info).
> >Does XVCG do the job?
[...]
> On the other hand, if you want a _call graph_ of your C code (which I suspect
> that you do, given that fact that you said that you want a list of functions
> that are ``used'') then there ought to be _some_ tool out there somewhere
> which will do that for you, but I confess that I don't know where you would
> get it off the top of my head. (Wouldn't it be nice if either GCC or LCC
> did this?)


One approach to extracting call-graphs that I found productive a
couple of years ago was to have the compiler generate .s
(assembly-language) files instead of .o (object code). Gcc's -S
option does this. Then I ran a complicated awk script over these .s
files that was able to determine caller and callee on its own for
direct function calls and that could use a separately-provided hints
file to learn that, e.g., "syscall_trap() can call any of the elements
of sysent[]" or "vn_open() can call the vn_create'th element of any of
the variables in the set `vnodeops' defined earlier".


My aim was to discover the maximum stack depth of any path through the
call-graph of a program. In the end this proved difficult because the
analysis found lots of bogus paths that were theoretically possible
but were ruled out by the semantics of the program, and some of those
paths involved cycles. I broke these cycles by judiciously deleting
edges from the generated call-graph, but it was not always possible to
do this in a way that reflected the real behaviour of the program.


I've put the awk script, the C program to determine maximum stack
depth, and some example input files in
    http://www.gr.osf.org/~emcmanus/programs/callgraph.html The awk
script will probably need to be modified for any new applications
because it has various dependencies on the machine-language (Intel
*86) and the symbol format (global symbols begin with _) but it may
nonetheless provide a useful starting point.


Eamonn McManus emcmanus@gr.osf.org http://www.gr.osf.org/~emcmanus/
--

Return to the comp.compilers page.
Search the comp.compilers archives again.