Recording (software debugging)

[Disclaimer: All Rights Reserved. You are welcome to reprint it. Do not use it for commercial purposes. Contact Email: feixiaoxing @ 163.com]

For many programmers and friends, writing code is much happier than debugging code. It seems that creating software is more rewarding than maintaining software. However, maintaining the code left by our predecessors in the enterprise is also an indispensable part of our work. Therefore, how to debug the software and find bugs in the software faster and better has become a lesson we must learn. Of course, some people find faults quickly, while others slow down. There are many reasons in the middle, such as the degree of familiarity with the business and the degree of use of debugging tools. This also shows that it is very important to master the software debugging skills. The content discussed here is not about how to use Visual Studio or GDB, kgdb, and systemtap for debugging, but about the basic principles of debugging software. After all, debugging software is also software, which requires support for chips, operating systems, compilation software, and stack formats.

(1) chip support

Many friends like to set breakpoints during software running, for example, inserting a _ ASM _ ("int $3": :) In the code can achieve this effect. The key is why this code is inserted. In the x86 chip, the INT 3 above will be translated into 0xcc. When the CPU encounters such a command line, it will generate an exception and then find the corresponding exception function for processing. There are special Debugging commands in x86, but such commands may not exist in some CPUs, such as PowerPC. What should we do at this time? In fact, it is also simple. You only need to replace the corresponding commands with commands that are not recognized by the CPU, which can also produce abnormal results. As to whether the current exception is a debugging exception, you need to determine the operating system.

(2) Operating System Support

The chip itself is only responsible for generating exceptions and finding exception handling functions. As for such functions, what else is the responsibility of the operating system. For example, if the program to be debugged has already run to a breakpoint, the operating system should notify GDB or Visual Studio that the current program has been run to the node. What should we do next. In general software debugging, functions are similar, such as viewing registers, checking memory, setting breakpoints, canceling breakpoints, viewing thread numbers, and continuing to run. These require the support of the operating system. Otherwise, how does GDB on the user side know where the current debugging program is running and where its basic information is. After all, GDB itself is also a software, and its specific information about debugging programs is told by others. It is not a god.

(3) Support for software compilation

With the support of chips and operating systems, you can debug the software. For example, wingdb does this. However, we are not very satisfied. Why? Sometimes, we also need to know the value of the function parameter, the global variable, whether it has changed, whether the C language code has the corresponding assembly code, whether it can implement Assembly-level debugging, and so on. Of course, this information is irrelevant to the running of the execution file, but it is used only when debugging the software. Therefore, the software versions compiled by Visual Studio include the debug version and the release version, the common software version, and the optimized software version. In Linux, for debugging purposes, people will also add the-G option to the GCC debugging options to obtain additional debugging information.

(4) stack support

In the software debugging, there is a very good content, that is, the function stack viewing function. The stack will be floating Based on the addition and reduction of temporary variables. It can be said that the master of the stack to master the CPU, master the programming, master the software debugging. In x86, EBP is a magic register. In the stack, EBP [0] saves the address of the previous EBP, and EBP [1] saves the address of the returned function. Through iteration, all function pointers can be obtained. Of course, the compiler can generate the systemp map file of the software, which records the spatial addresses of all functions. Associate the return address with the system map to know the function stack of the current Code. In addition, we can use the return address in the stack to set the breakpoint so that the breakpoint can be broken when the current function is running till the end, which is also very convenient to use.

void print_function_addr(int ebp, int level){    int* start;    int index;    if(0 == ebp || 0 == level)        return;    start = (int*)ebp;    index = 0;    while(index < level){        printf("[%d] 0x%08x\n", index, start[1]);        index ++;        start = (int*)start[0];    }}

(5) logs and counters

It is certainly not enough to rely on the system's debugging software. Therefore, in order to see the data operation process, we still need some additional debugging information. Therefore, for businesses, we need to store logs based on alarms, errors, and data formats. Of course, sometimes we need to measure and compare the Business Performance and frequency, so counters are also essential in many cases. This information is additional information beyond the normal code, so it is also a university question to deal with the relationship between them and the normal code. At the same time, logs are sometimes affected by multiple threads, efficiency, exceptions, and other factors. Therefore, you must be careful when thinking and executing logs.

(6) debugging principles

These debugging principles are just a summary of my personal experience. They are not insightful and are for your reference only. 1) first exclude the hardware and then the software. Attention should be paid to timing and signal integrity for special high-frequency signals; 2) software design is greater than debugging; 3) early software debugging benefits; 4) complex functional debugging can be performed on simulation software, for example, if the global address is out of bounds, It is very convenient to use GDB's conditional breakpoint debugging, but it is very difficult to search for embedded devices. 5) try to write the debugging function by yourself to continuously improve and optimize the processing, 6) The log module should be robust, especially suitable for multi-thread processing; 7) identify the root cause of the fault; otherwise, it is easy to generate new faults.