Why IAR produces different code size for Debug and release

[Vindhyachal.takniki]

1. I am using IAR for 8 bit MCU, IAR shared version: 8.3.2.5988

2. I have made code optimization and linker optimization settings same for both release and debug.

3. IAR by default on these keywords : DEBUG and NDEBUG  in debug and release mode respectively.

4. I searched for all the files even back end files but didn't find DEBUG & NDEBUG in my code or any other by default IAR file also.

5. But on building with space optimizations settings both have difference code sizes:

a) release:   7 600 bytes of readonly  code memory
    189 bytes of readonly  data memory
    335 bytes of readwrite data memory
   
B) Debug:   7 953 bytes of readonly  code memory
    189 bytes of readonly  data memory
    335 bytes of readwrite data memory   
   
   
6. What is causing so much change in memory?  For 8 bit MCU this is a lot. 

[mikerj]

You'll probably find that defining DEBUG compiles a bunch of asserts into the library code.

[radiolistener]

Debug version of code contains additional debug code and debug information. They are needed for debugging on source code level.

Also Release version may be more optimized and it's more hard to read it. Release profile usually disable adding debug information, so you will be unable to debugging it on source code level.

This happens with any compiler. Usually you can select your own optimization settings for Debug and Release profile. So, technically you can enable debug information and disable speed/size optimizations for Release profile.

The meaning of the profiles is to quickly switch between different compilation settings. Usually there are two profiles - Debug and Release. First is used for development and debug, the second for release. But you can add another profile in case of needs.

[ejeffrey]

I don't think the OP is asking about the difference between debug and release.  Rather that they attempted to change all the build options to be exactly the the same between debug and release and the binary sizes are still different.

A couple things to check.  The first is to actually look at the compiler and linker command as executed by the make file.  You will probably find some small difference there. It could be a symbol definition in which case mikerj's thoery is likely correct: there is some code such as asserts or boundary checks that is being compiled out completely on release builds.  I see you checked for instances of DEBUG and NDEBUG, but you might be missing some files such as platform include files or deeply nested macro expansion.  It could be linking against different libraries.  Any other difference in the executed commands could lead to a difference like this.  I have seen build systems that in the debug configuration linked in a console log function with a "keep" directive so the linker won't garbage collect it even if you never use it.

Another thing to look at is the size and contents of the pre-link object files created from each .c file.  This will tell you if the extra code is coming from compiler behavior or linker behavior, and if it is a compiler option it will tell you whether it is happing on each translation unit or only on one.

[Vindhyachal.takniki]

Did linker map file search here are results, left is debug and right is release. Files names are changed to aaa.o (please avoid)

Although compiler and linker optimization are same in both settings . These all aaa.o  files are my added, none of them are by default IAR added though, and in all their C files no DEBUG/NDEBUG I have added.

Checking each now.

[Siwastaja]

Choosing between DEBUG/RELEASE profile changes gazillion of settings; some of which may be hard to find. I wouldn't be surprised to find out some are even hard-coded to the IDE and impossible to change. The whole idea of the profiles is you can choose between two different sets of settings quickly. Why would you want to make them exactly the same? Just use the RELEASE profile if this is what you want?

You seem to assume the difference is only in optimization settings and in some #defines. But the most obvious difference is the addition of debug symbols to your binary. You can likely turn that off for the debug profile, too, if you want, but why would you do that?

[Vindhyachal.takniki]

If you have any zero initialized variables they will be stored in the memattr.bss section (see page 90 in the IAR C/C++ Development Guide).

The readwrite data is placed in the RAM and the readonly code and data in flash (if you haven’t specified it to a EEPROM area).

 
In the linker configuration file (*.lcf) you can see where all sections are placed. The easiest way to open your file (lnkstm8s003f3.lcf) is to expand the output folder and then the .out in you project (see attached file).


response from IAR team.