Foreword
Currently, we can use make/makefile to programmatically execute code files; we can use compilers such as gcc/g++ to compile code; we can use the vim editor to write code; in fact, there is also a tool in Linux that can achieve debugging Work, this tool is — gdb.
Before learning about the debugger, you should do something about the release version of your code:
In VS, before starting to execute the code, we can choose to execute the code in two ways: debug & amp; release:
Generally, debug mode is used during development. After writing the code, if our code is submitted to the remote end, and when it is in the hands of the customer, for example, in a company, it is submitted to the company’s warehouse using git, and the company can It is released as a release version. At the same time, the mode tested by testers is also a release version.
The debug version can be debugged, but the release version cannot be debugged. Moreover, the debug version code file is much larger than the release version file. The release version is also more efficient than the debug version.
The reason for the above differences is that the debug version of the code will generate debugging information when forming an executable file, and this debugging information is not available in the release version.
When using the gcc/g++ compiler to compile an executable file in Linux, the default is release mode. It cannot be debugged directly. If you want to publish it in dubug mode, you need to compile it with the -g option when compiling with gc/g++.
It is introduced in detail in the following blog, including how to view debug files, etc.:
Linux – Configure system whitelist – gcc/g++ _linux whitelist-CSDN Blog
gdb debugger
You can debug an executable file using the following command:
gdb executable file name
If, after using the above command, the following dialog box appears without any error, it means that you have now entered the debugging interactive interface:
As shown above, text is an executable program that can be debugged. The appearance of the above interface means that you have successfully entered the debugging interface.
If you want to quit, you can use q/quit.
At this time, we can’t see the code yet, because gdb uses the command line to view and debug the code, unlike Windows, which uses a graphical interface. We can directly see the code. to the code.
At this point, you can use list/l to view all code:
You can find that we used the command twice (once list and once l) to view all the code. In fact, using list/l alone will not necessarily display all the code from the first line . So, our parameters are:
l/list 0 (0 represents the line number, but it starts at any line in the code), which means starting from line 0:
The above only prints 10 lines. If we want to display all the code, there is a way:
When we use the command l/list 0, in fact, gdb will automatically record the previous command. When we press Enter (provided that < strong>l/list 0 after this command), he will think that we want to continue executing the list/l command at this time, then he will continue to display the code (displayed last time starting next to the last line):
Andat the end, you will be prompted with how many lines of code there are in total.
You can also use the following command to view all the code of a certain function in the code:
list/l function name
So when we are debugging, we must not just check the code, but first find the problem. For the problem, we can look at the error location, then guess the error location, and then use conditional breakpoints, or write in the code Stop code statements, such as using if to judge, stop when the program reaches which step. This method is especially suitable for codes with deep program stack frame iteration. For example, in the eight-digit problem, we are likely to Traverse into very deep state matrices (in the eight-digit problem, whether we use the A* or sm heuristic algorithm, we will traverse a lot of state matrices. These state matrices are when we move blocks, move different blocks, and move blocks Different positions will produce different state matrices (that is, an intermediate process)). For a detailed introduction to the eight-digit problem, please see the following blog: Eight-digit problem-c language_Eight-digit problem c language code_chihiro1122’s Blog-CSDN Blog
The reason why I cited so many examples above is to say: The most indispensable thing for debugging is breakpoints, whether it is at the beginning, for example, in VS we need to set a breakpoint, and then press F5 program It will run directly to the breakpoint and stop, and then we will proceed with debugging; another possibility is to set a breakpoint during the debugging phase. During the debugging process, you may also encounter troublesome parts of the program running. You can also during the debugging process Put a breakpoint in it to skip this step.
As a useful debugger, gdb must also support breakpoints. Next, we will explain the breakpoint method in gdb:
Run the program in gdb, break point
In the gdb debugging interface, use the r command to run the program directly:
Since we have not set a breakpoint in the program at this time, the program will run directly to the end at this time. When exiting, it will exit normally, just like F5/shift F5 in VS to start debugging.
Use In the gdb debugging window, use b line number to set a breakpoint on the specified line in the current debug file. At this time, we can use the r command to run from the program and stop at the specified breakpoint:
In VS, if we set a breakpoint on a certain line, we can directly see on which line the red breakpoint exists:
But in gdb, we cannot see this breakpoint. Even if we use l 0 to view the entire code after setting the breakpoint, we still cannot see the breakpoint:
In fact, using info b you can check the number of all breakpoint lines we have set:
We found that after using the info b command, not only the line number of the code where the breakpoint is located, but also some other information appears. The meaning of this information is as follows:
We found that breakpoints in gdb are numbered. When we delete a breakpoint, we cannot use the line number to delete the breakpoint as before, but should Delete a breakpointusing its number. In gdb we can use d breakpoint number
To delete a node:
Moreover, it should be noted that the breakpoint information we set is used within the current gdb running process. That is to say, each debugging information we set under the current gdb debugging window will not be used if we exit a gdb Then enter gdb to debug, even if it is the same file, the debugging information saved in the last gdb process will be deleted.
Perform statement-by-statement and process-by-process debugging in gbd
There are two statement-by-statement debugging methods in VS, one is F10 per process, and the other is F11 per statement.
Statement by statement is easy to understand, process by process actually means skipping a process, and a function can be called a process.
Use the n/next command to perform step-by-step debugging:
When we debug and run the code, there is one more piece of information in the breakpoint information: The number of times the breakpoint was hit:
Like the above two breakpoints, the number of hits is 1.
Use the s command for statement-by-statement debugging:
Monitoring window in gdb
The monitoring window in VS is also essential. Monitoring can greatly facilitate us to check whether a certain variable is currently legal, or we can check a lot of information. It depends on how you use debugging:
The debugging window is definitely indispensable in gdb, but because gdb is not a graphical interface, you have to manually enter a variable to let gdb know which variable value you currently want to view.
We use the p variable name/value after certain transformations of the variable command to view the value of this variable, or the value of this variable after transformation.
At this point we know that the value of variable a is 10 in the current program execution state.
Like the debugging window in VS, we can also view the address of a and other deformation information through the debugging window:
However, have you found that the above monitoring is too frustrating? You can also perform step-by-step debugging in VS, generally checking the values of variables, and the p above is typed out one by one.
In fact, there is also a constant display monitoring window command in gdb: display variable name/value after certain transformations of the variable , in this case, the input variable will always follow your debugging:
If you don’t want to display the variable value frequently, you can use the undisplay command, but this command cannot be followed directly by adding the variable name and other information to delete the monitoring of the variable information. Information:
It can be found that this is not possible.
It should be noted that among the variable information that is often displayed, each information has its own number. Like the above-mentioned deletion of breakpoints, it needs to be deleted according to the number, that is, use undisplay to always display the variable information number< /strong> Delete a frequently displayed message:
It can be found that the deletion is successful at this time.
For the often displayed message number, it is the leftmost number of the displayed message:
until jump instruction – finish ends the current function execution instruction
Suppose we are now in the loop body of a function and have fallen into this loop body, but we want to jump out of the current loop body and view the modified content after the loop body ends. At this time we can use until Specify row to jump to a certain row.
As mentioned above, when we use until to jump out of the loop body of a function, we need to check which line we want to jump to. If we just want to jump out of this function, we just need to finish executing the current function, and then check the line of this function. If the execution result is obtained, then we can use the finish instruction to end the execution of the current function when running in the function.
The usage scenario of finish, for example, is that the code currently written crashes, but there are many functions in the main function that we need to judge. At this time, if we want to know which function caused the code to crash, just You can execute a specific function and use finish to execute the function body to see which function caused the program to crash.
continue jumps to the next breakpoint
In VS, you must use F5 to jump to the next breakpoint. Using countinue in gdb can also jump directly from the current position to the next breakpoint.
Modify the Enb value of the breakpoint
Right-click the breakpoint in VS and you can choose to disable the breakpoint or enable the breakpoint. Similarly, there is the Enb value in gdb. This value has only two values, y or n, which means whether the breakpoint is enabled.
Use disable breakpoint number to modify the Enb value:
At this time, when we run the program, it runs directly to the third breakpoint, and the first and second breakpoints have been skipped (the above It is line 21 because the breakpoint at line 20 is a blank line and gdb automatically skipped it)
gdb command summary
There are many commands in gdb, such as the b command breakpoint. You can use b file name:line number to set a breakpoint at the line number of the specified executable file.
And b function name The breakpoint set in this way is essentially to set a breakpoint at the starting position of the function body, that is, the first line of code in the function body:
Summarize:
- list/l line number: Display the binFile source code, followed by the last position, 10 lines at a time.
- list/l function name: List the source code of a function.
- r or run: run the program.
- n or next: single execution.
- s or step: Enter function call
- break(b) line number: set a breakpoint on a certain line
- break function name: Set a breakpoint at the beginning of a function
- info break: View breakpoint information.
- finish: Execute until the current function returns, then wait for the command
- print(p): Print the value of the expression. The value of the variable can be modified or the function can be called through the expression.
- p variable: print variable value.
- set var: modify the value of a variable
- continue (or c): execute the program continuously rather than single-step from the current position
- run (or r): execute the program continuously from the beginning rather than step by step
- delete breakpoints: delete all breakpoints
- delete breakpoints n: delete the breakpoint with serial number n
- disable breakpoints: disable breakpoints
- enable breakpoints: enable breakpoints
- info (or i) breakpoints: See which breakpoints are currently set
- display variable name: track a variable and display its value every time you stop
- undisplay: Cancel tracking of those variables that were previously set
- until X line number: jump to X line
- breaktrace (or bt): View function calls and parameters at all levels
- info (i) locals: View the value of local variables in the current stack frame (equivalent to viewing the local variables dialog box in VS)
- quit: exit gdb
The knowledge points of the article match the official knowledge files, and you can further learn relevant knowledge. Cloud native entry-level skills treeHomepageOverview 16,717 people are learning the system