在IAR的Workspace窗口顶部的下拉菜单中有两个选项

admin管理员组

文章数量:1540710

2024年6月13日发(作者：)

IAR

的

Workspace

顶部下拉菜单中

Debug

和

Release

区别

Hanson-he

在IAR的Workspace窗口顶部的下拉菜单中有两个选项，Debug和Release。名字和

数量可以在菜单栏的Project-->Edit Configuration中增删修改。每个选项都对应着一种配置

（也就是项目名称右击Options里的内容），互相是独立的。所以用起来很方便，直接在不

同的配置间切换。

realse版本与debug版本的区别如下：

DEBUG版本和RELEASE版本的区别：DEBUG版本里会包括基本的调试信息，供开

发和调试使用；而RELEASE版本不会包括调试信息，一般是发布给用户使用。所以你会

发现DEBUG版本的SIZE比RELEASE版本会大许多。另外，RELEASE版本在编译链接

的时候检查会更严格，所以有时候会出现DEBUG版本能使用，而RELEASE版本却会出

现一些问题的情况。编译器优化级别，链接器输出文件的格式(是否包含调试信息等) ，当

然，debug和release这两种build configuration的属性，在project创建完之后是可以任意

修改的。

虽然可能在Release版本下没有问题，但是并不等于说程序没有Bug，只是由于运行

库进行了优化和丢弃，问题没有明显的展现出来，这样隐含式的错误后期很难再找出来，即

使发现了，也由于编码的原因，修改困难。所以考虑还是在开发的阶段尽量的用debug方

式编译和修改，当在debug模式下没有问题以后再改为release生成给客户运营用。

一、Debug 和 Release 编译方式的本质差别

Debug 通常称为调试版本，他包含调试信息，并且不作所有优化，便于程式员调试程

式。Release 称为发布版本，他往往是进行了各种优化，使得程式在代码大小和运行速度

上都是最优的，以便用户非常好地使用。Debug 和 Release 的真正秘密，在于一组编译

选项。下面列出了分别针对二者的选项（当然除此之外更有其他一些，如/Fd /Fo，但差别

并不重要，通常他们也不会引起 Release 版错误，在此不讨论） Debug 版本：/MDd /MLd

或 /MTd 使用 Debug runtime library（调试版本的运行时刻函数库）; /Od 关闭优化开

关;/D "_DEBUG" 相当于 #define _DEBUG，打开编译调试代码开关（主要针对assert函

数）;/ZI 创建 Edit and continue（编辑继续）数据库，这样在调试过程中如果修改了原始

码不需重新编译;/GZ 能帮助捕捉内存错误;/Gm 打开最小化重链接开关，减少链接时间.

Release 版本：/MD /ML 或 /MT 使用发布版本的运行时刻函数库,/O1 或 /O2 优化开关，

使程式最小或最快,/D "NDEBUG" 关闭条件编译调试代码开关（即不编译assert函数）,/GF

PDF created with pdfFactory Pro trial version

合并重复的字符串，并将字符串常量放到只读内存，防止被修改。实际上，Debug 和

Release 并没有本质的界限，他们只是一组编译选项的集合，编译器只是按照预定的选项

行动。事实上，我们甚至能修改这些选项，从而得到优化过的调试版本或是带跟踪语句的发

布版本。

再来逐个对照这些选项看看Release版错误是怎样产生。runtime library：链接哪种运

行时刻函数库通常只对程序的性能产生影响。调试版本的runtime library包含了调试信息，

并采用了一些保护机制以帮助发现错误，因此性能不如发布版本。编译器提供的runtime

library 通常很稳定，不会造成 release 版错误；倒是由于 debug 的 runtime library 加强

了对错误的检测，如堆内存分配，有时会出现 debug 有错但 release 正常的现象。应当

指出的是，如果 debug 有错，即使 release 正常，程序肯定是有 bug 的，只不过可能是

release 版的某次运行没有表现出来而已。

优化：这是造成错误的主要原因，因为关闭优化时源程序基本上是直接翻译的，而打开

优化后编译器会作出一系列假设。这类错误主要有以下几种：

帧指针(frame pointer)省略（简称 fpo ）：在函数调用过程中，所有调用信息（返回地

址、参数）以及自动变量都是放在栈中的。若函数的声明与实现不同（参数、返回值、调用

方式），就会产生错误。但 debug 方式下，栈的访问通过 ebp 寄存器保存的地址实现，

如果没有发生数组越界之类的错误（或是越界“不多”），函数通常能正常执行；release 方

式下，优化会省略 ebp 栈基址指针，这样通过一个全局指针访问栈就会造成返回地址错误

是程序崩溃。c++ 的强类型特性能检查出大多数这样的错误，但如果用了强制类型转换，

就不行了。你可以在 release 版本中强制加入 /oy- 编译选项来关掉帧指针省略，以确定是

否此类错误。此类错误通常有： mfc 消息响应函数书写错误。正确的应为 afx_msg lresult

onmessageown(wparam wparam, lparam lparam); on_message 宏包含强制类型转换。防

止这种错误的方法之一是重定义 on_message 宏，把下列代码加到 stdafx.h 中（在

#include "afxwin.h"之后）,函数原形错误时编译会报错 #undef on_message。#define

on_message(message, memberfxn) { message, 0, 0, 0, afxsig_lwl,

(afx_pmsg)(afx_pmsgw)(static_cast< lresult (afx_msg_call cwnd::*)(wparam, lparam) >

(&memberfxn) }。

volatile 型变量：volatile 告诉编译器该变量可能被程序之外的未知方式修改（如系统、

其他进程和线程）。优化程序为了使程序性能提高，常把一些变量放在寄存器中（类似于

register 关键字），而其他进程只能对该变量所在的内存进行修改，而寄存器中的值没变。

如果你的程序是多线程的，或者你发现某个变量的值与预期的不符而你确信已正确的设置

PDF created with pdfFactory Pro trial version

本文标签： 版本错误优化