On Wed, 2 Jun 2004, [iso-8859-1] Jörn Engel wrote:

> Yeah, I know about the problems to generate a complete call graph.
> With function pointers, it is plain impossible to get it right in the
> most general case.
> 
> Note the "in the most general case" part.  You can get things right if
> you make some assumptions and those assumptions are actually valid.
> In my case the assumptions are:
> 1. all relevant function pointers are stuffed into some struct and
> 2. no casts are used to disguise function pointer as something else.
> 
> If you stick with those rules, the resulting code is quite sane, which
> is much more important than any tools being usable.  If the kernel
> doesn't stick to those rules for a good reason, I'd like to know about
> it, so I can adjust my tool.  And if the kernel doesn't stick to those
> rules for no good reason, the code if broken and needs to be fixed.
> 
> Is this sane?

Think at file_operations as very simple example, and try to find out what 
is actually called when somewhere the code does f_op->*(). How would you 
build the graph down there. You'd have to record all the functions that 
have been assigned to such method throughout the code, and nest *all* 
their graph in place. And this will eventually trigger false positives. 
Similar thing with functions that accepts callbacks, either directly or 
inside structures. And this doesn't even start to take aliasing into 
account. Hunting stack hungry functions is very good, and having a tool 
that is maybe 60% precise in detecting loops is fine too. But requiring 
metadata to be maintained to support such tool is IMO wrong.



- Davide