Chapter 7. Testing and Debugging

In this chapter

7.1	Using the GNU Debugger	page 446
7.2	strace and ltrace	page 460
7.3	cscope Utility	page 460
7.4	glibc Debugging Support	page 463
7.5	Memory-Debugging Tools	page 466
7.6	Static Program Checker	page 472
7.7	Threads trace Tool	page 473
7.8	Performance Monitoring Tools	page 474
7.9	Summary	page 491

As the project enters the final stage of the porting process, there is a lot to look forward to. We enter the testing and debugging phase with great anticipation because this is the most interesting part of the process. This is where all the hard work of making sure the build process works and the application compiles and links with all the necessary libraries comes together. This is the moment of truth! You go into the directory where all the executables of the application are located. You have read the user documentation on how to run the application. With mixed feelings of anticipation and trepidation, you type in the executable name on the command line and press Enter.

Like any software application development project, application porting projects need to have the supporting tools available that will enable porting personnel to debug and tune the application. Although GDB is the only popular application debugger in Linux, a multitude of available tools can help make the porting task easier and alleviate the process of finding difficult runtime application problems such as memory leaks and performance bottlenecks.

We present tools that aid application development and porting such as strace and ltrace as an alternative to the truss facility available on other operating platforms for tracing program execution. To help increase porting productivity by allowing porting engineers to find symbols used within an application more quickly than tools such as grep, we describe an underrated tool called cscope and discuss how to use it with the Vim editor.