Tags:
create new tag
, view all tags
from http://cscope.sourceforge.net/:
Cscope is a developer's tool for browsing source code. It has an impeccable Unix pedigree, having been originally developed at Bell Labs back in the days of the PDP-11. Cscope was part of the official AT&T Unix distribution for many years, and has been used to manage projects involving 20 million lines of code!

...

Features:

  • Allows searching code for:
    • all references to a symbol
    • global definitions
    • functions called by a function
    • functions calling a function
    • text string
    • regular expression pattern
    • a file
    • files including a file
  • Curses based (text screen)
  • An information database is generated for faster searches and later reference
  • The fuzzy parser supports C, but is flexible enough to be useful for C++ and Java, and for use as a generalized 'grep database' (use it to browse large text documents!)
  • Has a command line mode for inclusion in scripts or as a backend to a GUI/frontend
  • Runs on all flavors of Unix, plus most monopoly-controlled operating systems.

See:

Contents

Notes

  • On 13 Apr 2003, I wrote to Hans-Bernhard Broeker with a question about whether Cscope can handle functions called by function pointers. I'm quoting his answer in its entirety here (instead of on Xsm20030413). I probably will want to reread his answer more than once -- the last paragraph, in particular, is probably giving me an important "clue":

Re: Can Cscope Handle (Trace) Functions called by Function Pointers?
Date: Mon, 14 Apr 2003 12:07:57 +0200 (MET DST)
From: Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de>
To: Randy Kramer <rhkramer@fast.net>

On Sun, 13 Apr 2003, Randy Kramer wrote:

> "... automatic cross-reference tools are not very useful on the whole 
> code because there's lot of important points where functions are called 
> through function pointers and these tools cannot cross those borders, 
> leaving an incomplete call tree."
> 
> Can cscope deal with that problem?  

Almost not at all. Typically, it'll already fail to recognize a function pointer (type) definition as such, because of the way it analyzes source code --- it's too easily thrown off its path by what appear to it as gratuitous pairs of parentheses. This is a known (and documented) design limitation of cscope, and has been ever since the tool was created, AFAIK. It can help if the code religiously uses typedefs for function pointer types --- which is recommended style anyway. And if it uses new-style call syntax (no parentheses around the pointer variable). But don't expect miracles.

More fundamentally, function pointers add confusion to what a "call tree" is, or should be. IMHO, calls through pointers cannot be part of a call tree determined by source code analysis, nor should they be. What's failing here is the idea behind the analysis method "call tree", not the tools that generate it for you. Only actual call-counting by a profiler, as part of a full code coverage test, can tell what the call tree really is in the presence of function pointers.

It's strictly impossible to know by code inspection (-->Turing, the halting problem) which functions a given pointer might be pointing to, at a given time, so every time a function pointer is used to make a call, in principle you would have to mount every function of the whole program (and all the libraries) below that node as possible called ones --- which is not helpful at all. Listing none of them is just as fine, then.

Maybe the representation chosen by RedHat SourceNavigator is the wisest one possible: it gives the name of the function pointer itself as the called function where the call is. And it lists the place where the function pointer is assigned to point to some particular function as a "read" access to the function, which is not part of the call tree itself.

This reveals what this really is about: because of function pointers, the call tree and the variable/type usage tree are not truly separate concepts in the analysis of C code.

Contributors

  • () RandyKramer - 14 Apr 2003
  • If you edit this page: add your name here; move this to the next line; and include your comment marker (initials), if you have created one, in parenthesis before your WikiName.

Page Ratings

Topic revision: r1 - 2003-04-14 - RandyKramer
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look