Shulou(Shulou.com)06/03 Report--

This article focuses on "what are the differences between Debug mode and Release mode". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn the difference between Debug mode and Release mode.

Friends who use CumberCraft + all know that there are various optimization levels for compiler compilation, and the compiler optimization levels are roughly as follows:

O0 (default option): do not enable optimization to facilitate function debugging

Og: an optimization option for debugging (more conservative than O1)

O1: conservative optimization options, with more than 40 optimization options open

O2: a commonly used release optimization option that opens more than 40 optimization options on the basis of O1, including rules such as automatic inlining

Os: an optimization option that produces a smaller code size (more conservative than O2)

O3: a more radical optimization option (with the lowest tolerance for error coding), which opens more than a dozen additional optimization options on top of O2

Ofast: turn on performance tuning options that can cause non-compliance with standards such as IEEE floating-point numbers.

The details are as follows:

O0: the compiler defaults to O0. Optimization is not enabled under this option, which is convenient for developers to debug.

O1: committed to minimizing code size and running programs as fast as possible without requiring too much compile time, it turns on the following optimization flags:

-fdelayed-branch-fdse-fforward-propagate-fguess-branch-probability-fif-conversion-fif-conversion2-finline-functions-called-once-fipa-modref-fipa-profile-fipa-pure-const-fipa-reference- fipa-reference-addressable-fmerge-constants-fmove-loop-invariants-fomit-frame-pointer-freorder-blocks-fshrink-wrap- fshrink-wrap-separate-fsplit-wide-types-fssa-backprop-fssa-phiopt -ftree-bit-ccp-ftree-ccp-ftree-ch-ftree-coalesce-vars-ftree-copy-prop-ftree-dce ftree-dominator-opts-ftree-dse-ftree-forwprop-ftree-fre-ftree-phiprop-ftree-pta-ftree-scev-cprop-ftree-sink-ftree-slsr-ftree-sra-ftree-ter-funit-at-a-time

Og: if it is for debugging, this option is a better choice than O0. It turns on most of the O1 optimization flags, but does not enable those that affect debugging:

-fbranch-count-reg-fdelayed-branch-fdse-fif-conversion-fif-conversion2-finline-functions-called-once-fmove-loop-invariants-fssa-phiopt-ftree-bit-ccp-ftree-dse-ftree-pta-ftree-sra

O2: a common Release level under which almost all supported optimization options are implemented, which increases compilation time, increases the speed of the program, and turns on the following optimization flags:

-flra-remat-foptimize-sibling-calls-foptimize-strlen-fpartial-inlining-fpeephole2-freorder-blocks-algorithm=stc-freorder-blocks-and-partition-freorder-functions-frerun-cse-after-loop-fschedule-insns2-fsched-interblock-fsched-spec-fstore-merging-fstrict-aliasing-fthread-jumps-ftree-builtin-call-dce-ftree-pre-ftree-switch-conversion-ftree-tail-merge-ftree-vrp

Os: turns on almost all O2 optimization flags, except those that often increase code size:

-falign-functions-falign-jumps-falign-labels-falign-loops-fprefetch-loop-arrays-freorder-blocks-algorithm=stc

It also enables the-finline-functions optimization flag to allow the compiler to optimize based on code size rather than program speed, in order to reduce code size.

O3: the following optimization flags are turned on on the basis of O2

-fgcse-after-reload-fipa-cp-clone-floop-interchange-floop-unroll-and-jam-fpeel-loops-fpredictive-commoning-fsplit-loops-fsplit-paths-ftree-loop-distribution-ftree-loop-vectorize-ftree-partial-pre-ftree-slp-vectorize-funswitch-loops-fvect-cost-model-fvect-cost-model=dynamic-fversion-loops-for-strides

Ofast: a more aggressive compilation option that does not strictly follow the standard. On the basis of O3 optimization, it opens some performance optimization options that may lead to non-compliance with standards such as IEEE floating-point numbers, such as-fast-math,-fallow-store-data-races, etc.

Tips: if you want to know the exact meaning of the above optimization options, please refer to the https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html official documentation.

The compiler has so many optimization levels, the Debug version and the Release version are actually the difference between the optimization level. Debug is called the debug version. the result of the compilation usually contains debugging information without any optimization, which is convenient for developers to debug. Release is called the release version, which does not carry debugging information. At the same time, the compiler makes a lot of optimizations to the code to make the code smaller and faster and release it to users. Give users a better experience. But the Release schema also takes more time to compile than the Debug schema.

There are some differences in memory allocation in Debug mode. When we apply for memory, Debug mode will apply for more space, which is distributed before and after the memory block to store debugging information.

Uninitialized variables are initialized by default in Debug mode, but not in Release mode, so there is a common problem that Debug mode and Release mode behave differently when local variables are not initialized.

Bool func () {bool found; for (int I = 0; I < vec.size (); + + I) {if (vec [I] = = 3) {found = true;}} return found;}

It may work fine in Debug mode, but an error result may be returned in Release mode because the found local variable is not initialized in Release mode.

Debug mode allocates memory in 32 bytes. For example, when applying for 24 bytes of memory, 24 bytes are allocated normally in Release mode, while 32 bytes are allocated in Debug mode, with an increase of 8 bytes. Therefore, some array out-of-bounds problems can be safely run in Debug mode, while problems will occur in Release mode.

Assert can be used in Debug mode, if there are anomalies in the process of running, assert will not be compiled in crash,Release mode, crash will not be compiled in time when unexpected circumstances are encountered, and it will continue to run in confusion, and strange errors may occur in the later stage, which is not easy to debug, but it does not realize that the problem occurred a long time ago. The compiler defines the _ DEBUG macro in Debug mode and the NDEBUG macro in Release mode. The preprocessor determines whether assert is enabled or not according to the corresponding macro.

Data overflow problem, in a function, there are some variables that have never been used, and there is a data overflow problem in the function, which may not cause a problem in Debug mode, because the variable will not be optimized, it still occupies a few bytes in the stack space, but there may be problems in Release mode, this variable may be optimized in Release mode, and the stack space becomes smaller accordingly, and the data overflow will lead to stack memory corruption. It is possible to make strange mistakes.

For example:

Void func () {char buffer [10]; int counter; lstrcpy (buffer, "abcdefghik"); / / need to copy 11 bytes} so far, I believe you have a deeper understanding of "what's the difference between Debug mode and Release mode". You might as well do it in practice! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.