cancel
Showing results for 
Search instead for 
Did you mean: 

What is the difference between debug and release, of a project

AKuma.2074
Associate III

Hi,

I am completely new into microcontrollers. And while working with keil as well as smt32cube ide i found options such as debug and release.

Can someone please tell me whats the difference between both, what benefit one has on other and when to use when.

Thanks and regards

1 ACCEPTED SOLUTION

Accepted Solutions
TDK
Guru

The difference is the compiler settings. Release is much more optimized, resulting in faster and smaller code, but is harder to debug since some source code statements may be removed/rearranged. Variables may be optimized out entirely.

I would use Debug exclusively unless performance becomes an issue. It is much easier and more productive to keep the configuration the same rather than to try to maintain two configurations. Bugs that don't appear in Debug may appear in Release.

If you feel a post has answered your question, please click "Accept as Solution".

View solution in original post

16 REPLIES 16
TDK
Guru

The difference is the compiler settings. Release is much more optimized, resulting in faster and smaller code, but is harder to debug since some source code statements may be removed/rearranged. Variables may be optimized out entirely.

I would use Debug exclusively unless performance becomes an issue. It is much easier and more productive to keep the configuration the same rather than to try to maintain two configurations. Bugs that don't appear in Debug may appear in Release.

If you feel a post has answered your question, please click "Accept as Solution".

Optimization Level

Stack Checking

Asserts

Verbose Diagnostics

Additional symbolic and line numbering information in objects

Stuff that would tend to aid debugging and testing phases of the software/hardware

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Thanks

Thanks

it is whatever you configure it to be!

@TDK​  and @Community member​  have given you some typical examples.

Actually turning on optimization, especially the higher levels, can reveal many serious code flaws. Missing volatiles, race conditions will fail with a high probability. Therefore optimization should be used as a part of testing even if it is not used in a production build.

As for settings... For example EmBitz IDE has a two level configuration - project and build levels. One typically sets all the common settings like CPU architecture, directory paths etc. at project level and only the optimization and few other build specific settings at build level.

mattias norlander
ST Employee

Quite complete answers already provided by community. Just a few more points.

Default optimization levels in GCC for the configurations:

  • Debug --> Optimization off -O0
  • Release --> Optimize for size -Os

If you run low on memory when using "Debug" due to -O0, then you could switch this configuration to rely on -Og which introduces optimization that should not disturb the debug experience.

There are also different philosophies on addressing optimization levels in build configurations.

Some developers thinks that Release and Debug should have as similar optimization related settings as possible in order to make sure that you "debug what you ship and ship what you debug".

Yes, optimisation should ideally be the same as higher levels often expose defects related to undefined-behaviour - the optimiser assumes there is none present, and code generation can "break" if there is (a little example, where the defect completely breaks the code at -O2, but not at -O0 ).

Though it isn't fun using a debugger with aggressive optimisations enabled!

Why would that example "break", and why would it behave differently at -O0?

JW

PS. For reference, this is the code under the link:

extern void error();

typedef enum { S0 = 3, S1 = 13 } T;

bool f()
{
  static T state = S0;

  switch ( state  )
  {
    case S0: state = S1; break;
    case S1: state = S0; break;
    default: error();    break;
  }
//  return state == S1;
}