c / c ++ under summarize some debugging experience

For 2 years, did a year ARM embedded platform, a year back, two years experience in the development of debugging are summarized below. I put debugging tools divided into two kinds: print logs and analysis tools. Because usually the main development in the Linux platform, it is an example to GDB

First, the print log

1. Set the log reasonable level

General log database will have the log level, the rational use of the environment can avoid the lines too large to print the log disk usage is too high, the log search takes too long, because the log size exceeds the set value, resulting in one day Print Log counted more than other issues. Log online environment generally requires the following levels:

Info, went variables represent business information critical point of time, the number of consumer queue, waiting for the number of processing these location services are normal, index information needed to analyze program performance

Warn, a state program should not happen under normal circumstances, but not a fatal error

Error, program exception, or has hung up

The test environment can be set to Debug log level when the function test, the final code delivery, can be provided with Debug-level log, but be sure to leave log to ensure streamlined and clear. A streamlined debug log, you can replace most functions within comments

2. good at using the built-in debugging macros

Several macro c ++ offers: __ FILE__, __FUNCTION__, __LINE__ help locate the code location

void Foo(){
    //error here
    Log.Error<<__FUNCTION__<<"  is errors in Line["<<__LINE__<<"] varable is "<<var<<endl;
}

Of course, some of this information comes libraries

3. Log division

Multithreading, a module may have multiple business processes. Preferably divided according to the service, or partitioning the log module. For example, a database operation log a log, and a communication middleware message. Easy to archive log management

Finally, talking about streamlining the problem log, do embedded development during the first year, basically, it is the only print the log debugging method. Each time the code change, you need to compile, and then burn to see the log information on the device, the high efficiency of the log is very helpful in locating the problem. A log or need to play, we want to be reversed, when the development of functional problems, information on what areas do I need? The information, which is necessary, and with this information, I can locate the code in question is probably where it is. Then the rest is unnecessary information