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.

 

There is code that is generated to facilitate debugging. This code serves no useful version in the release code so it is eliminated.

 

353 bytes doesn't seem like "so much". But you can compare the map files to see exactly what is different.

 

If both options generated the same code, then there wouldn't be any point to having both options.

The release version is the code you want to give to your customer. In general you want it to be as clean and efficient as reasonable and you also want it to have as few security vulnerabilities as possible. But when you are developing your code youwant to be able to step through the code and set break points and be able to get meaningful diagnostic messages, so you compile the debug version that inserts additional code and information into the executable to facilitate this. This additional code not only makes the file larger, but it generally reduces performance somewhat. Worse -- and something that is almost always overlooked -- is that it opens significant security vulnerabilities either because the attacker can use the same debugging hooks to take over the program or they can use the additional information to better analyze the code in looking for weaknesses. So you should always ship the release version of your code. Unfortunately there's a lot of shipped code out there that is the debug version, either because the developer is completely unaware of the difference and most compilers insert debug code by default, or because they are concerned that the release code won't work the same as the debug code (and this is a valid concern because they ARE different and sometimes that difference does matter, even though the compiler writers go to significant lengths to make this not the case).

 

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.

 

I once had a discussion with Keil engineer, he said this though:

 

The engineer didn’t say that the output file is unchanged. He said YOUR code isn’t changed. Debug adds additional code to the output file without changing your code. At least that’s how I interpret his comments.

 

response from IAR team.

 

Sometimes code (your own code or library code) is explicitly included or excluded based on the the DEBUG or NDEBUG compiler flags. For example, anything in an ASSERT macro is typically present in debug builds but removed from release builds. Also compare the optimization flags; debugging optimized code can be a nightmare, so typically deubg builds have little or no optimization while release builds are often optimized for speed and/or space, both of which can affect binary size. Also your binary release builds will typically have the symbols stripped out while debug builds will not, and symbols take up space. @WBahn pretty much nailed it above; debug and release builds are not identical. Compiler writers try their best to make them behave identically from a developers point of view, but there are often differences.