Tools for reading source code under Linux

It's a shame to say so. have been using VIM to develop. But I don't know if VI has such a good tool. Used to always use:

Find-type F-print | Xargs grep-i * * * * * in the source code to find.

The original Linux also has a similar souce Insight tool. The following is an article referring to others. http://blog.chinaunix.net/u1/56619/showart_1822993.html

Comparison of Linux source code analysis and reading tools

The source reading tool under Windows Souce Insight, with its ease of use and the support of a variety of programming languages, is undoubtedly the "lead brother" in this field. What about the Linux/unix environment? Still seems to be in blossom, the difference between the spring and autumn Warring States period, in fact, it seems that any software under its environment is in a zhuluzhongyuan situation, perhaps this is the "market" in the "cathedral" advantage of it! The main cross-index tools are:ctags , cscope , global , lxr , Kscope , Sourcenav , CallTree , Codeviz , NCC, Gprof and so on. The following will be a brief introduction of the merits and demerits of each software. In this, I currently analyze their source code has LXR, Sourcenav, CallTree, NCC. Now I'm going to make the transformation I need based on Sourcenav to better analyze the kernel needs. Kscope needs to go through a review and analysis, if Kscope's code analysis capabilities (that is, the ability to scope) to keep up with Sourcenav may be abandoned sourcenav go to kscope development, because Sourcenav interface and interactivity is not good.

1. Ctags

Ctags should be a few of the oldest one, of course, also get the most support, vim default support Ctags generated tag database, but the original ctags true, only support C language, and analysis is not delicate. Its new version is exuberant Ctags, but it has gone far beyond its name, supporting 33 programming languages, including C, with good accuracy, and its development is still in full swing, promising Ah!
With vim use, basically can satisfy the user's request.
Common commands:
To create a database command:

Exuberant-ctags

Browse in the VIM editor:

: Ta x Jump to the definition of symbol X, if there are multiple symbols, jump directly to the first place : TS X List the definition of symbol X : TJ X Can be considered as the merge of the above two commands, if only one symbol definition is found, then jump directly to the symbol definition, if there are more than one, let the user choose their own. CTRL +] Jumps to the definition of the symbol at the current cursor, similar to TA. Ctrl+t Jump to the previous symbol definition, and the above mates are basically free to jump. Two additional: TN: TP is a jump between multiple definitions of a symbol

In the ointment, can only find the definition of symbols, can not achieve cross-reference query and other functions.

2. Cscope

Compared to Ctags can only find the definition of the symbol, Cscope is more rich, although he supports the C language, but it can find the definition of the function, but also to find out where the function has been called, so to a certain extent to compensate for the shortcomings of the ctags.
Common commands:
To create a database command:

Cscope and Vim are used together:

The VIM document is no longer repeated, by the command itself
: Help Cscope
Go to learn more about it.

Unfortunately, Cscope's last update was in 2003, and the project seemed to have been abandoned, hoping to be adopted later or merged with other projects.

3. Global

Global is a GNU-produced cross-index tool that supports C, C + +, YACC, Java, and PHP4 in five languages, with good command-line performance, but with Vim, it's better than the previous two. Its characteristic is that the analysis is very delicate, I have studied, temporarily can only soucenav can surpass it. A Web page that can generate a cross-index, well suited to the documentation used to make the program. The database was changed from Berkeley BD 3. But there is a big gap between what I want and what I need. Because it has only one front end of the web, in functionality, his existing front-end also implements only symbolic queries and cross-reference queries.

4. LXR

The Linux hypertext cross-code search tool, LXR, was written by the Arne Georg Gleditsch and per Kristian Gjermshus of the University of Oslo, Norway. This tool is actually running on Linux or Unix platforms, and by indexing all symbols in the source code, you can easily retrieve any symbol, including functions, external variables, filenames, macro definitions, and so on. Not only for Linux source code, but for other large-scale projects in C, you can build their LXR site to provide developer query code, as well as follow-up developers learning code.
The current LXR is designed specifically for the Apache server under Linux, by running Perl scripts, retrieving the source code index files, and sending data to Web browsers on network clients. Web browsers on any platform can be accessed, which makes it easier for users who are accustomed to working under the Windows platform. About LXR's English website for http://lxr.linux.no/, in the Chinese Linux forum http://www.linuxforum.net has its mirror image.
All right, I'm done. To say the shortcomings, I may not analyze the depth, its code is not written in C, is a Web page script, the program is also very short, do not see the application database. A lot of things are generated when you browse, so the potential to use or transform is limited, and the code analysis is not enough global fine.

5. Kscope

Kscope is a graphic front-end for Cscope, who is not familiar with vim or is not accustomed to the terminal work of the people to provide a graphical interface, the interface is a highlight of this software, than the source insight is also good-looking, People who turn around from windows to do Linux development may feel more cordial. This is why I have been tempted recently. In addition, it has a fascinating feature: the ability to generate function call trees. But said hundred, in fact, is called Graphviz draw out.

6. Sourcenav

Snavigator is a good source code editor and project management software. There are Windows and Linux versions. URL Http://sourceforge.net/projects/sourcenav.
Basic Description: Source-navigator is a Source code analysis tool. With it, you can edit your source code, display relationships between classes and functions and all, and display call Trees.
This tool claims to be the source insight is a Linux opponent, and indeed, after my round of Google, from the analysis of performance, only he and source insight can be parallel. But the operability is far from the source insight strong, many functions with no source insight to the liking. The interface is far worse than Kscope, which is why I am kscope. And the source insight, there is no point is that the need to generate a cross-reference is done in the background, but it is a one-time continuous generation, and the source Insight generation is, it is more preferential to generate the customer's current code, source Insight This is a good consideration for customers. The database is also Berkeley BD 4, he and global, as in the use of the database, the first table used only two word end, key and data, that is, no use of secondary Databases, which resulted in a lot of time to return all records, Then the optimization program to filter, this way to the advantages of the database is buried, to know that the Linux this type of original code, cross-reference database may reach hundreds of m, so dry memory is not enough, speed also not to talk about. I have not studied kscope I do not know how it is in this respect, I think sourcenav this aspect must be rid of. The work of filtering data is done entirely by the database, and they do it well.
Can be developed, sourcenav do well, there are user documentation and development documents, code structure is more likely, TCL programming is also straight to easier. The function can be expanded on the basis of its original function. The next few series of blog, I will be the source of its analysis.

7. Other Source analysis tools

In addition to the above-mentioned system of more complete tools, there are a lot of analysis of the small tools. Most of these gadgets are used to draw function call graphs.

Drawing a function call graph is useful for understanding large programs. I think we all had one. Read the source (and maintain a call stack in the mind), draw a function call relationship on paper, and then organize the experience of the diagram. If you're lucky, you can save some brainpower with the debugger's single-step tracking and call stack windows. However, if you want to analyze the script language code, it is likely to be honest with the first method. Wouldn't it be nice to have a call graph handy before you read the code? Here are a few of the free tools I know to analyze the function call relationships of C + +.

A function call graph is a graph (graph) and is a directed graph, mostly a no-loop graph (without a circle)-if there is no direct or indirect recursion in the code. Graphviz is a tool designed to draw both the graph and the graph, so many call graph analysis tools use it as the backend (back end). What about the front end? Just look at the recount of the family.

The analysis and analysis of call graph can be divided into "static" and "dynamic", so-called static analysis is to analyze the program without running, then the dynamic analysis is the actual operation of the recording program function call situation.

Static analysis has two methods, one is to analyze the source code, and the second is to analyze the compiled target file.

The quality of the call graph that is obtained by analyzing the source depends on how well the analysis tool understands the programming language, such as the ability to find the correct overloaded C + + function. Doxygen is the source document tool, can also draw the call graph, it seems to be their own analysis of the source code to obtain a function call relationship. The GNU Cflow is a similar tool, but it seems to be biased toward the Analytical Flowchart (flowchart).

The best way to understand the programming language is the compiler, so someone came up with a patch for the compiler to record the function call relationship at compile time. Codeviz (a tool inspired by Martin Devera Devik) belongs to this category, and it (1.0.9) has patched gcc 3.4.1. Another tool Egypt the idea of a more ingenious, do not have to make a fuss to the compiler to patch, but let the compiler itself dump out the call relationship, and then analysis and analysis, to Graphviz to draw. But someone has to write a C language compiler (NCC), a special analysis of the call graph, the courage is commendable. If you do this to the C + + language, the cost is too high. Analyze the call graph of C + + or use the compiler to compare reality.

Analysis of the target file sounds very advanced, in fact, the work of the disassembly to binutils objdump to do, as long as the analysis of the disassembly of the text files on the line. Below is a partial result of objdump-d a.exe under Cygwin:

00401050 <_main>:
401050:       55                       push  %EBP
401051:       e5                    mov   %ESP,%EBP
401053:        EC 18                 sub    $0x18,%esp
   ...
40107a:       C7 40    movl   $0x402000,0x4 (% ESP)
401081:    &n

401082:c7 movl $0x402002, (%ESP)
401089:e8 F2-xx-401180 <_fopen>

As you can see, main () calls fopen (). Codeviz with the ability to parse the target file.

Dynamic analysis is a call to log a function while the program is running, and then organized into a call graph. Compared with static analysis, it can obtain more information, such as the sequence of function calls and the number of times, but there are some shortcomings, such as the application of some branches of the statement may not be executed, the functions called in these branches are naturally not recorded.

There are two methods for dynamic analysis, one is to use the call graph function of gprof (parameter-Q), and the other is to utilize GCC -finstrument-functions  parameters.

The output generated by the gprof is as follows:

Index% time self children called name
0.00 0.00 4/4 Foo [4]
[3] 0.0 0.00 0.00 4 Bar [3]
-----------------------------------------------
0.00 0.00 Init [5]
0.00 0.00 Main [45]
[4] 0.0 0.00 0.00 2 Foo [4]
0.00 0.00 4/4 Bar [3]
-----------------------------------------------
0.00 0.00 1/1 Main [45]
[5] 0.0 0.00 0.00 1 Init [5]
0.00 0.00 Foo [4]
-----------------------------------------------

As you can see, bar () is called by Foo () 4 times, and Foo () is called once by Init () and main (), and Init () is called once by Main (). Using the Perl script to analyze the output of the gprof and generate the Graphviz dot input, you can draw the call graph. This script has been written by more than one person: http://www.graphviz.org/Resources.php, http://www.ioplex.com/~miallen/.

The purpose of the-finstrument-functions parameter of GCC is to add hooks to the program to invoke each of the following functions at each entry and Exit Function:

void __cyg_profile_func_enter( void *func_address, void *call_site )
                                __attribute__ ((no_instrument_function));
void __cyg_profile_func_exit ( void *func_address, void *call_site )
                                __attribute__ ((no_instrument_function));

Of course, the two functions themselves cannot be hooked (using the no_instrument_function __attribute__), or they will never be exhausted:) Here is the function address, need to use binutils in the Addr2line this gadget to convert to the function name, if it is a C + + function, but also use c++filt name Demangle. Specific methods in the "Use Graphviz visual function call" in detail, here no longer repeat.

From the adaptability, the source code analysis is the strongest, even if there is grammatical error in the source code, the head file is not all right, it can still analyze a sorta. Compiler-based analysis of the requirements of the source code is higher, at least can be compiled through (gcc parameter-c)-can produce an object file, not necessarily linked to the executable file. This requires at least no syntax error in the source code, where the function called is not necessarily defined (definition), but there is a declaration (declaration), that is, the header file to complete. Of course, it's really not all right, I put a few function declarations in front can fool the compiler:) As for dynamic analysis, the highest requirement-the program needs to be run. If you are analyzing a certain part of the operating system, such as memory management or the network protocol stack, then the two dynamic analysis methods mentioned here are probably not applicable.

8. Other resources on the Web

[1] program analysis under the Linux platform using the GNU Gprof
[2] The DOT Language
Http://www.graphviz.org/doc/info/lang.html
[3] graphviz-graph visualization software
http://www.graphviz.org/
[4] Coverage Measurement and Profiling
http://www.linuxjournal.com/article/6758
[5] visual operation with Graphviz-draw function call graph
[6] Cscope
http://cscope.sourceforge.net/
[7] KFT (Kernel Function tracing)
Http://elinux.org/Kernel_Function_Trace
Ftp://dslab.lzu.edu.cn/pub/kft
[8] Call Graph--Gprof
Http://sourceware.org/binutils/docs-2.17/gprof/Call-Graph.html#Call-Graph
[9] various types of analysis function call Graph tool
Http://oss.lzu.edu.cn/blog/blog.php?do_showone/tid_1636.html

Tools for reading source code under Linux