Am Mittwoch, den 13.10.2010, 14:54 -0700 schrieb Joe Buck: > On Wed, Oct 13, 2010 at 02:43:18PM -0700, Sebastian wrote: > > On Wed, Oct 13, 2010 H.J. Lu wrote: > > > gcc can not dump a callgraph. Both GNU ld and gold can dump a > > > cross-reference table, which is not a call graph but could perhaps be > > > used to produce a call graph. See the --cref option. > > --cref isn't much use. It doesn't tell me which functions call other > > functions, only which modules refer to them. > > > > Static analysis which work on source code are not ideal, either. They > > don't know which functions will be inlined by the compiler. > > > > So it would be nice if gcc could provide a call graph. > > gcc compiles only one object file at a time; to produce a call graph you'd > need data produced by the linker. gcc cannot provide a call graph. > > To get a call graph, you'd need to combine data produced by the compiler > (with stack-usage) and data produced by the linker (--cref). It probably > wouldn't be too hard to produce such a tool using a scripting language > (perl or python, say) to parse the outputs from the compile and link > steps. > Of course, the compiler can't dump the callgraph of the whole program. But it could dump the list of functions called by every function of a translation unit. With annotations which of the calls are inlined. Which could then be processed by a script to get the whole callgraph.
For a script, it would be quite difficult to get a callgraph out of --cref. What if a function is called from several functions of the same file (which the script knows from static source code analysis) but only some of the calls are inlined? I think, the reason that the linker only gives a list of referenced symbols per file name, and not per function, is that it can't do better. I doesn't know where the code of a function starts and ends. Does it? Sebastian