Hello Ioannis; Ioannis E. Venetis wrote:
> > Would __builtin_stack_size (F) retrieve information about F's stack frame > > only, or would it also recursively account for every other function that > > F may call ? > > > > Implementing the former is probably possible, though I'm not sure > > exactly how useful it would be. > I agree that the former is probably not very useful. If a function is > set to run as a thread and it calls other functions, the stack required > for those functions should be accounted for. Probably the second option > is much more useful. Sure. It's unfortunately not really an option for complexity reasons. > I had a look here: > > http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Static-Stack-Usage-Analysis.html > > I think that the best would be __builtin_stack_size(F) to return what is > described as "dynamic" and "bounded" in the above link. I'm afraid there is a misunderstanding here. What -fstack-usage outputs for each function is information about the stack used only by the function itself. There is no relationship with what the functions it calls do. The "dynamic" qualifier states whether the function itself allocates dynamic amounts of stack, like with an "alloca (n)" and "n" a variable. The extra "bounded" qualifier states whether we know a bound for such dynamic allocations. > Except from recursive functions, what are the other cases where the > above size cannot be computed statically? Functions often call functions in other compilation units, so this almost always is a non-straightforward inter-unit computation issue to start with. This is what the accompaning -fcallgraph-info is about, together with some tool to merge the per-unit graphs and perform computations on the outcome. Then, any form of indirect call is a potentially hard source of difficulty and there are several variants of those across the languages supported in GCC. Third, functions we don't compile often come into play. And I'm probably forgetting a couple :)
