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循環里出不來