From: Petr S. <pe...@sc...> - 2001-06-18 20:59:54
|
Hi Darryl, Comments below: > [ I'm cc'ing cscope-devel, as I need as many inputs as possible on > this. ] > > Here's the story thus far: I mentioned to Petr that I want to add > some functionality to cscope that will allow me to get a recursive list > of functions called by a function, etc., like: > > entercurses [main.c(1339)] > nonl > cbreak > noecho > wclear > mouseinit [mouse.c(88)] > mygetenv [mygetenv.c(40)] > getenv > strcmp > loadmenu [static in mouse.c(170)] > mousereinit [mouse.c(201)] > printf > fflush > printf > mousecleanup [mouse.c(215)] > printf > strlen > fflush > drawscrollbar [mouse.c(233)] > printf > > Now, I know that there are other tools, like calls(1) and cflow(1), that > will do the same thing (in fact, I faked the above list using > calls(1)). However, they don't create any databases for quick lookup, > and so they can run slowly. I want something that runs quickly on LARGE > source trees (>10000 files). > > Here is Petr's response (and mine): > > > That sounds pretty good. Can you let me know how you plan to display > > this info. Via command line options only? > > Well, I'm not sure if it belongs in cscope, and so I was planning > on doing most of the work using tools outside of cscope. > > [ Well, conceptually, it belongs, but it would require cscope > maintaining two parallel databases. While this can be done, it's a > bit distasteful, aesthetically. ] > > I'm willing to be talked into something else, but here's my current > plan: > > 1. Modify cscope to add an option that will cause it to output the > functions called by a function, for all functions; cscope already has > this functionality, but you must specify a particular function. > > [ The hard part in this project is determining what functions are > called from a given function, and cscope does wonders for solving > this. ] > > 2. Write another tool (in perl) that parses the output from (1) and > writes a Berkeley DB database. The database would simply be a DB > version of (1) -- given a function, the functions directly called by > it could be quickly looked-up. > > 3. Write another tool (in perl, command-line callable) that, given a > function, recursively lists/prints functions called from a function, > etc.. The database created in (2) would be used for this, and the > output will be done in command-line mode only (there will be no > full-screen display, although that could, conceivably, be a good > enhancement). > > I will also have an XEmacs interface to this. > > Now, steps (1) and (2) could be merged into cscope, but I'm not sure if > that really should be done. We'd have two different databases being > maintained by cscope. If you do need to touch cscope, just implement step (1). The main reason is that for cscope 16.0 we are going to probably move the database into something more universal (like BDB or another choice.) This will allow cscope to maintain your options (2) and (3). > A bit problem with this simplistic approach is that large source > trees often have duplicate functions (e.g., more than one main(), for > testing). With this approach, all of the called functions from all of > the duplicate functions would be merged together and be displayed. Now, > it's possible to have the user specify which (of 1-N) top-level > functions to use, but I can't think of any way to determine the correct > non-top-level functions (I may just have to live with it). Also be careful of not generating call sub-trees as unique sub-trees (although this should not be a problem.) Thanks for tackling this Petr > > Comments? > > -- > Darryl Okahata > da...@so... > > DISCLAIMER: this message is the author's personal opinion and does not > constitute the support, opinion, or policy of Agilent Technologies, or > of the little green men that have been following him all day. > > _______________________________________________ > Cscope-devel mailing list > Csc...@li... > http://lists.sourceforge.net/lists/listinfo/cscope-devel -- -------------------------------------------------------- Petr Sorfa Senior Software Engineer Caldera 430 Mountain Ave. http://www.caldera.com Murray Hill 07974 NJ, USA -------------------------------------------------------- Disclaimer: All my comments are my own and nobody else's ---------------------------------------------------------- |