Re: show size of stack needed by functions

[Sebastian <sebastianspublicaddress at googlemail dot com>]

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