Stanfo Programming Tutorial-Unix programming tools (III)

There may be one or two bugs in your program, and there are many ways to find bugs, but a good debugger can make this work easier. In most programs of various sizes, it is almost impossible to find out all the bugs in the program. You can only keep staring at the code-you need to identify the bug through the behavior when the program is running. It is worth investing some time to study the debugger.

GDB
We call the GNU Debugger GDB, which exceeded DBX in almost every field and works perfectly with the GCC compiler. Some other beautiful debugging environments include ups and codecenter, but they are not as common as GDB, and codecenter is not cheap. Although GDB does not have a graphical interface as beautiful as other software, it can provide almost all the information they want to know for high-end programmers.

This section does not describe every detail of GDB in depth, but we will mention the important part. We can use the help command to view the online help of GDB. If you need more information, try to use the xinfo command on the terminal or use the Info-browser mode of Emacs.

Start debugging
There are two methods to call GDB in make. To start the debugger in shell, you only need to input the following in the terminal:
GDBProgram

Program is the target executable file for debugging. If you do not specify any target when calling GDB, GDB will ask you to specify the target file after startup, and then you can do something useful.

Another option is to use [ESC]-X to call GDB when using Emacs. Then, you will be prompted for the executable file name. If Emacs does not specify a target, you cannot use GDB. The Emacs window is split into two parts, one displaying GDB information and the other displaying source files.

Run the debugger
When you start running, the debugger loads your program and its feature tables (including useful information such as variable names and source files ). This feature table is generated by the compiling condition-G. The debugger will read this information to run the program.

The debugger is an interactive program. When it is started, it will prompt you to enter commands. The most common commands in the debugger include setting breakpoints and one-step debugging, run again after the breakpoint and check the value of the variable.

Run the program
Run the reset program to start running from the very beginning. You can provide some parameters during running in the same way as running a program on a terminal.
Step: trace the call in one step, run the code in the next line of the source file, and return to the debugger. If a subroutine is called, The subroutine is tracked.
StepCountRun the "count" line to the source code.
The next one-step call does not track subprograms.
Finish runs until the current method or function is complete.
Return returns the frame of the selected stack to its caller.
JumpAddressRun the program from a certain place or line

When a target executable file is selected for the first time, the current source file is the file where the main function is located, and the current code line is the first line of code executed in the method.
When you are running a program, it will always run to a line of some source files. When you pause the program (when the Program Stream encounters a breakpoint ), the current target file is the source file of the currently executed code. Similarly, the current source code line is the line of code you execute.

Breakpoint
You can set a breakpoint on a line in the program. Each breakpoint is set with a number, and then you can manipulate it by number.
You can use the break command to set the breakpoint where you want the program to stop. The breakpoint location can be set in many ways, for example, you can use a file name, a row number, or a method name (the actual running code in the row must be included. Note and space cannot be included ). If the file is not specified, it is the current target file by default. If no breakpoint is set, the current code line is the breakpoint.
GDB provides the following commands to control breakpoints:
Info break: print the position and status of all breakpoints at the beginning.
BreakFunctionSet a breakpoint at the beginning of the specified method.
BreakLinenumberSet a breakpoint in a specific row of the current source file.
Break filename:LinenumberSet a breakpoint on a specific line of a specific file.
You can also set an if statement to create a conditional breakpoint:
Break FN if expression stops at the breakpoint when the expression value is positive. The expression can be any c expression. When a breakpoint occurs, the current stack is used for calculation.
Disable/enableBreaknumOn or off a breakpoint.
DeleteBreaknumDelete the breakpoint of a row
CommandsBreaknumSet the command to be run when the program runs at the breakpoint. The command can be any c Declaration or GBD command. This can be used for real-time Encoding without re-compilation (Great !).
Cont continues to run the stopped program.

For example, the following command...
Break Binky. C: 120
Break dogoofystuff

Set a breakpoint at line 120 of Binky. C, and the other breakpoint is at the first line of the dogoofystuff method. When the program runs to these locations, the program will stop asking you to obtain some information in the debugger.
GDB and most other debuggers provide a mechanism to determine the way the program runs. We often ask where I run the program (A) and the variable value in the Program (B ).

Check Stack
To answer question (a), we can use the breaktrace command to check the running stack. The running stack is similar to the footprint left when the program runs. When a method is called, the running stack is created. When the method runs to return, the running stack is cleared, then the stack will be recycled. These stack frames contain variable information of a series of call statements and the parameters passed by each method call. The method call statement redirects the current operation to the corresponding method.

GDB sets the stack frame to an ordered frame from 0 to infinity. At any time, GDB uses only one frame as the current frame. For the selected frame, the search for the variable is OK. When the program encounters a breakpoint during debugging, GDB selects the innermost frame. The following commands can be used to select other frames by serial number or address.
Backtrace displays all stack frames, which are useful when looking for call sequences that cause program crashes.
Frame framenumber check frame number is framenummber frame. This operation does not change the running context, but allows variables in Different frames.
Click down to select and print the called stack frame.
Up selects and prints the stack frame that calls this method.
Info ARGs displays the parameter variables of the current stack frame.
Info locals displays the local variables of the first frame stack.

Check source files
Another way to find the running location of the current program or find other useful information is to check the corresponding source file. GDB provides the following names:

ListLinenumPrint the source fileLinenum10 lines of code.

ListFunctionPrint 10 lines of code near the start of the method.

List: print the following 10 lines of code.

The list Command prints the code lines in the source file that are centered on the current behavior. If you use GDB in Emacs, these commands are too old.

Check Data

If you want to answer "What are the values of these variables ?", Then you should use the following command...

PrintExpressionPrint the expression value. The expression is a valid C expression, which can include method call and arithmetic expression, and all variables of the current stack frame.

SetVariable = expressionSet the variable value to the value represented by the expression. You can set the values of all variables in the current range. All variables starting with $ can be used as temporary variables of GDB.

DisplayExpressionThe expression value is printed when the program runs until it stops. It is very useful if you want to view the value of the variable when you run the program step by step.

Undisplay cancels the previous display command request.

In GDB, there are two ways to display the value of a variable: display the value of the current variable once or continuously display the value of the entire life cycle of the variable. The print command prints the value of the current variable, and the display command prints the value of the variable at every step of the program running, as long as the variable still exists. The target value is distinguished by the C syntax, for example...

Print x. y [3]

The fourth variable value of the array named Y in the X struct is printed. Variables that can be accessed exist in the active frames of the current method, as well as global variables and static variables. Both print and display can be used to print arbitrary complex expressions, or even expressions containing method calls. But if there is a method that has side effects, you have to pay attention to it.

Abbreviations

Finally, we can use GDB more simply, that is, all commands can be abbreviated, so you don't have to execute all the commands every time. The abbreviation of a command is to replace the command with a small amount of letters without ambiguity. Some special Commands include break, delete, run, continue, step, next, print, you only need to use the first letter when using it. In addition, you only need to press the return key to display the last command you entered. This is very useful when you view the variable value during single-step debugging.

More commands
Editmode mode sets the command line mode of GDB. The Mode value can be Emacs, Vi, dumb.
Shell Command runs the remaining programs just like running programs on the terminal.
History prints the history of commands used.

Debugging Policy
Some people do not want to use the debugger because they do not want to learn other tools. This is wrong! It takes some time to learn how to use a debugger and its features, which will make it more efficient to eliminate difficulties.

In many cases, bugs may cause program crashes (or "kernel crashes" or "Registration machine crashes .), Then your program will be stuck there, leaving only prompts such as "film interruption. If your program crashes like this, the debugger can have captured the program signal, which contains the errors it has found and allows you to check the program status. In this way, you will not be able to make much effort to display the state of the program when it crashes.

Under normal circumstances, a bug does not cause a major program crash, but rather generates symptoms of internal problems. In this case, a technology is to set a breakpoint where the program is not running normally, and then get some data by observing the stack call situation, and then control the program to a bad state. Another technology is to set some power-off before the problem starts, and then step by step approach the problem, always check the running status.