cc250编译调试测试

㈠ vc上怎么调试c#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
合并重复的字符串，
并将字符串常量放到只读内存，
防止被修改
实际上，Debug
和
Release
并没有本质的界限，他们只是一组编译选项的集合，编译器只是按照预定的选项行动。事实上，我们甚至可以修改这些选项，从而得到优化过的调试版本或是带跟踪语句的发布版本。
OK，知道了这些，谁还会说RELEASE版本不能调试？
只需要设置相应编译环境，RELEASE同样可以像DEBUG版本设置断点，查看参数。
步骤如下：
1、在Project
Settings里选Settings
For为All
Configurations。
2、在C/C++标签中，Debug
info
选
Program
Database。
3、在Link
标签中，Category选
Debug，选中Debug
info
复选框和Microsoft
format。
现在就可以像在Debug版本中那样设置断点进行测试了，但是记住，Release版本由于代码优化，有些变量是观察不到的，行的运行顺序可能也会不同。

㈡ 什么是调试和测试

调试是程序完工前的工作，调试前的程序一般都不是正确的，调试后才是正确的。
测试是程序基本完成以后的步骤，一般是作为正确性验证的，测试可能会发现问题，但是应该不会满是问题。

㈢ CCS中 Debug 和 Release 编译方式的区别

Debug 为调试版本，Release 为发布版本，从开发者和用户视角看，他们的区别如下：

一、从开发者视角，Debug和Release的区别，主要是编译器的选项不同，Debug 包含调试信息，并且不作任何优化，便于程序员调试程序。Release 往往是进行了各种优化，使得程序在代码大小和运行速度上都是最优的，以便用户很好地使用。

Debug 版本 相关参数解释：
参数 含义
/MDd /MLd 或 /MTd 使用 Debug runtime library(调试版本的运行时刻函数库)
/Od 关闭优化开关
/D "_DEBUG" 相当于 #define _DEBUG,打开编译调试代码开关(主要针对assert函数)
/ZI
创建 Edit and continue(编辑继续)数据库，这样在调试过程中如果修改了源代码不需重新编译
GZ 可以帮助捕获内存错误

Release 版本 参数含义
/MD /ML 或 /MT 使用发布版本的运行时刻函数库
/O1 或 /O2 优化开关，使程序最小或最快
/D "NDEBUG" 关闭条件编译调试代码开关(即不编译assert函数)
/GF 合并重复的字符串，并将字符串常量放到只读内存，防止被修改

二、使用者视角，我们下载软件的时候，一般应该选择Release版。Debug一般比测试版更粗，主要提供给高级测试者反馈修改意见。

㈣ 当程序不能编译时怎么办调试configure

但是，这样行不通时怎么办？在本文中，Peter Seebash 讲述了当自动的配置脚本失效时应该如何去做——以及作为开发者您应如何尽量避免这种错误。毕竟，如果您的程序无法编译，其结果将和您的程序编译后不能运行一样，您的用户会减少。
现在许多开放源代码的程序都会附带有 configure 脚本。这种脚本的用途之一是自动进行对目标新系统的猜测过程。在过去，程序会附带一个 Makefile 文件，这个文件中有 6 个不同的编译标记和选项，但只会用到一个，其余全部注释掉，并且会有一个注解，告诉您“为您的系统选择合适的标记”。如果配置选项更复杂，可能还会有一个名为 config.h 的长长的 C 头文件，其中包含一些要设置的标记，这依赖于主机系统变量。
第一个方法很简单，在代码中使用 #ifdef 以支持两种系统，例如 BSD 和 System V。由于 Unix 的类型的增加，更为实用的方法是对每一个特性使用 #ifdef。每个系统的代码如下：清单 1. 每个系统的代码#ifdef SUNOS4 || NEXT || NETBSD || FREEBSD || OPENBSD
#include <string.h
#else#include <strings.h
#endif每个特性的代码如下：清单 2. 每个特性的代码#ifdef HAS_STRING_H
#include <string.h
#else#include <strings.h
#endif后者更容易适应新系统，但需要开发者进行大量的工作。由于现在有太多可能的目标系统，因此，第二种方法对用户来说帮助很大，不仅仅是可以自动生成配置头文件。完成这项任务的一种方法是使用 GNU autoconf 代码来生成 configure 脚本。这个脚本会去执行必要的测试，并创建一个具有适当值的配置头文件。
这种脚本的另一个功能是以一致的方式设置预定义的变量。用手工编辑标记一直存在一个问题，即修改了 Makefile 文件（比如将其安装到 /usr/gnu 而不是 /usr/local 目录下）却忘记修改头文件中相应的值。当然，这样的结果是，编译后的程序不知道到哪里去寻找它们自己的数据文件。使用 configure 脚本的一个好处是可以自动完成一致的安装（如果维护者做得没错的话）。
开发人员请注意，一个好的 configure 脚本的另一个好处在于，它会允许用户指定一些个人偏好，例如使用 /usr/gnu 而不是 /usr/local。
这些如何成为可能？编译，再编译configure 的许多功能实现机制其实很简单。为了能切身体会，您可以设计一个小测试程序，这个程序当且仅当期望的条件得到满足时才可以编译。将它保存在一个临时文件中，然后尝试编译它。例如，假定您想知道 X Windowing System 是否安装在 /usr/X11R6 目录下。一种方法是做一个如下的测试程序：#include <X11/X.h
int main(void) { return 0; }现在，如果您用编译器来尝试进行编译，那么只有当 <X11/X.h 在编译器的 include 路径中时，编译才会成功。因此，对每一个您认为 X 可能安装到的目录，可以将对应的 (directory)/include 加入到编译器的 include 路径中，并尝试对程序进行编译。如果采用某个值时示例文件可以编译，那么您就得到了正确的 include 路径。
请注意在 autoconf 中已经预定义了各种测试程序。如果可能，就直接使用这些测试程序，而不用自己去写。这样有很多好处。首先，autoconf 的新版本会改进这些测试程序，修正它们的错误，否则您将不得不自己去做这些工作。其次，这样会节省您的时间。当然，更好的方法是完全避免测试。如果您确认某一个测试是没有必要的（例如，即使机器字节多于 8 位也仍需要使 sizeof(char) 为 1），您可以完全不去进行这个测试。
有一些测试是功能测试；它不足以确定是否存在一个名为 memcmp() 的函数，它的语义必须正确。通常，这些测试用于只是在一两个平台上被注意到的非常不明显的错误。这些测试实际上会去运行测试程序，并检查它的输出。测试程序遵循标准的 Unix 习惯：如果测试通过则返回值为 0，如果失败则返回一个非 0 值。
一旦您有了足够的测试程序，您可以用它们来自动确定必需的编译标记和定义，以将它们放到头文件的某个地方。通常，configure 脚本会允许用户给出部分或全部已知的条件，而不是让脚本自己去猜测。
来看一个特例，假定，系统的 brokenmemmove() 出现了问题。如果您不知道它现在有一个只会影响少部分程序的 bug，您可能会编译一个程序并将其发布为产品，而没有意识到这样您将会遇到偶然的灾难性错误。
在许多情况下，一个冗长而复杂的 configure 脚本的最终结果是这样的：目标系统提供了这个程序用到的每一个标准特性，而且它们正确工作。在这种情况下为什么不手工去设置这些标记呢？这对开发者来说是可行的，而对众多用户来说就不可以了。用户可能不会知道到他们的 linux 版本存在特定的 bug。他们可能不知道已经安装了哪些软件包，或者安装到了何处。脚本帮那些最需要帮助的人来完成大部分的例行公事的工作。当脚本出错时，引发的额外工作的代价可能不会太大。
错在何处？既然您已经基本上了解了 configure 都做了些什么工作，您可以开始寻找错误了。有两种可能的 configure 错误。一种是 configure 是正确的，而您的系统缺少必要的先决条件。绝大多数情况下，configure 脚本会正确诊断出这种错误。更为麻烦的情况是 configure 本身的错误。这样的结果或者是不能生成配置，或者生成一个不正确的配置。
当 configure 的猜测无误，而您缺少先决条件时，您所要做就是要满足缺少的那些先决条件。当您找到并安装好后，再重新运行那个报告缺少先决条件的 configure 脚本，就可以成功了。（不要忘记删除 config.cache 文件，这个文件缓存了上一次测试的结果；您应该让 configure 从头开始。）如果您正在开发 configure 脚本，您需要确保您给出的错误消息有意义。如果您测试的是一个函数，而这个函数是一个常见的可添加的软件包的一部分，那么不要告诉用户缺少的函数的名称 —— 告诉用户他们需要的软件包。确保将先决条件信息写入 README 文件中。并且，请一定要告诉人们您测试使用的其他软件包的版本号。
阅读文档无论何时，当 configure 失败时您首先要做的是运行 configure -h，并检查参数列表。如果它找不到您确认已经安装的库，您可能可以指定到另一个位置来找到这个库。您还可以禁用和启用某些特性。例如，用于 Angband （一个 Roguelike 游戏）的 configure 脚本有一个可选的标记 —— enable-gtk，以告诉脚本在编译时启用 GTK 支持。如果没有这个标记，编译时根本不会去尝试。
如果您的系统配置得比较奇怪，您可能不得不为 configure 脚本设置一些非常详细的变量，而且如果是在交叉编译，您很可能得做一些非常特别的事情。CC 是 configure 用于指定 C 编译器的变量，通过指定 CC 的值可以解决许多问题。如果您指定了编译器，configure 将使用那个编译器而不用去猜测需要使用哪一个。要注意的是，这样您可以在命令行中指定选项和标记。例如，如果您希望编译时支持调试符号，尝试：CC="gcc -g -O1" ./configure（这里假定您使用的是 sh 系列的 shell；在 csh 中，用 setenv 来设置环境变量 CC。）阅读 config.log当 configure 脚本运行时，它会创建一个名为 config.log 的文件，其中记录的是测试日志和得到的结果。例如，一个典型的 config.log 片断如下：清单 3. config.log 的典型内容configure:2826: checking for getpwnam in -lsun
configure:2853: gcc -o conftest -g -O2 -fno-strength-rece conftest.c -lsun &5
ld: cannot find -lsun
configure:2856: $? = 1
configure: failed program was:
(a listing of the test program follows)如果我的系统中，-lsun 应该提供 getpwnam()，我应该可以使用命令行来对其进行确切检查，然后再使用测试程序。只需进行少量这样的调试，我就可以根据得到的信息来修改 configure 脚本。请注意有帮助的行号；这个测试从 configure 脚本的第 2,826 行开始。（如果您是一个 shell 程序员，您可能会喜欢在阅读 configure 脚本片断时打印出行号；在 shell 中 $LINENO 不能自动地被扩展为合理值，脚本使用 sed 创建一个包含有行号的自身拷贝！）当一个测试失败或者得到意外的结果时，最好先去读一读日志文件。请注意，有时测试失败仅仅是因为上一个测试的失败，这种失败实际上并不重要。例如，configure 可能会因为找不到一个您闻所未闻的库而退出，而这可能是因为测试标准 C 库中某个功能的程序失败而导致无法找到那个库。在这种情况下，只需要解决第一个问题，第二个问题也就不会再出现了。
一种情况是测试程序设计不正确而可能

㈤ gcc 编译生成外部调试语法文件

你用的是linux系统吧？ binutil包里面有个objcpy命令：
obj --only-keep-debug [被提取的文件] [提取出来的调试符号文件,建议加.debug后缀]

另外要把调试信息去掉是用strip命令。你可以man下看看。
strip --strip-debug [需要处理的文件]

把debug信息加回去：
obj --add-gnu-debuglink=[debug文件] [需要添加debug信息的文件]

㈥ TinyOS中cc2530编译或烧写时总是出现这样的状况，怎么回事，求大神赐教啊！

可能是环境搭建的不对吧

㈦ 在VS2010的VC++中如何编译、链接、运行、调试程序

看图说话！

㈧ C语言中编译 生成 调试 测试 运行各是什么意思有什么区别

C语言中编译 生成 调试 测试 运行的区别如下：

区别一：

从编译方面来看：

编译依赖于编译器，英文是compile, vc中这一过程是将源代码转换成目标文件，如：obj文件，rc文件等。

区别二：

从生成方面来看：

生成指的是连接的过程,英文是build，依赖于链接器。vc中在这一阶段将所有的目标文件和所有需要用到的组件组合成一个整体，例如需要生成的是windows系统下的PE可执行文件，链接器会依照特定格式将目标文件组合，最后生成PE格式的，exe或dll文件。

区别三：

从调试方面来看：

调试是所有或部分代码编写完成后，让程序在调试器中运行，用这种手段对程序进行分析，找出并修正潜在问题。

区别四：

从运行方面来看：

运行就是让程序在系统中运行。

(8)cc250编译调试测试扩展阅读：

C语言的介绍：

C语言是目前流行的通用程序设计语言,是计算机专业人员和计算机爱好者开发软件的首选开发工具。C语言源程序必须经过某种编译工具翻译成为目标机器语言程序才能够在计算机上执行。

然而随着程序编写规模的扩大，顺利编写出正确的程序绝非一件容易的事情，早期的许多编译工具仅仅提供翻译功能，已满足不了应用的要求，编程人员需要-种功能全面并高度集成的编译环境。

程序是一段具有一定功能的代码，编写程序的目的是解决问题。当程序人员写完程序后，其实并不起作用，只有当编写的程序经过一系列的处理后，能够解决问题时。

序才成为真正的程序，这一系列的处理过程，-般就是编辑、编译、连接、调试与运行等。目前最成熟的C语言集成环境主要有Turbo C2.0和Turbo C 3.0( 简称TC30)或Borland C++3.1( 简称BC31)以及Visual C++ 6.0。

㈨ C语言调试和编译一样吗

部分同意两位楼上的，编译是把源文件转化为目标文件（一个二进制文件一般后缀名为.obj,.o），如果不报错的话，在链接成可执行文件.exe，这时才可以运行
调试则是为了找出在程序中的错误，使测试用的，当然，如果是一个小程序而且能运行通过，可以偷偷懒不调试。但是如果是一个比较大的程序，对正确性和健壮性要求很高的话，那就需要老老实实的调试找出里面隐含的逻辑错误等

㈩ CC2530为什么在线编译时停在了串口发送函数中出不来了

1.在for循环里出不来
2.在while循环里出不来