編譯器指令單步跟蹤

⑴ Visual C里有沒有像Turbo C裡面的單步跟蹤的功能

這只是兩個不同的編譯環境而已

都可以編譯C 和C++

語法 是C與C++ 的區別，不是編譯器的區別

VC 比Turbo C 更直觀，調試更方便 編譯的時候 行縮進等都是自動的，可以使得編程的不需要一直使用tab來縮進

不過 VC使用的時候要建立工程 然後文件是包含在這個工程裡面

最後直接生成 .exe文件

turbo C 在 C++圖形界面和應用Application方面要差的很多

VC很龐大，可以建立任何想要的工程文件 可以創建mfc 等 這是tc所不具備的(好像是，turbo C 用的不是很久沒發現這些，具體有沒有還得問高手)

最早的時候，我就是使用的turbo c,後來改用 VC++ 個人感覺還是VC好用的多

至於所謂的語法問題 都是一樣的 VC可以執行C++ 也可以執行C文件 所以語法根本都是一樣的
如果還沒解決你的問題，可以加我網路HI賬號。

⑵ 在用keil編譯程序時，單步跟蹤到某一步莫名奇妙的跳轉的別的函數去了，有可能是什麼原因造成的啊

1:你的程序唄優化了 也就是說你的游標處不是真實編譯後的匯編執行的地方
2：你的確在這調用了函數 或者跳轉。（要知道很多運算符都是調用的庫函數）

⑶ c++.5.0編譯器怎麼單部調試

調試是為了找錯和改錯，一般都用單步調式，監視代碼的運行。
編譯嘛就是運行前的一步操作，利用編譯程序從源語言編寫的源程序產生目標程序的過程，幫你把源代碼翻譯成機器能識別的代碼。
運行就是產生結果嘍。

⑷ 有關C++中單步跟蹤的細節

你的程序可能執行進入了一段匯編代碼
因為系統的有些函數是無法深入跟蹤的
調試器就給你了一段反匯編得到的代碼

單步跟蹤的一般是利用step over(F10),step into(F11),這兩個操作讓程序一步步（但這個步長是不固定的，可能是一個基本語句也可能是一個函數）運行。
單步跟蹤可以不用打斷點，直接在編譯程序成功後，執行step over 或step into調試器就會啟動。

你繼續看調試工具欄上的按鈕，你會發現其他的一些非單步的調試方法。[step out(shift+F11), continue(F5)]continue的執行方式是，程序不斷執行，直到調試器碰到斷點才停止。

建議多利用斷點結合F5調試程序，這樣效率更高，也對程序員推測BUG具體位置的能力有一定要求

而設置斷點在VC中也是有很豐富的條件的，可以有很高級的斷點設置方法讓程序只在指定的條件下在指定的位置暫停。

⑸ 匯編語言中關於jmp far ptr的一個疑問

首先要明白編譯的過程,編譯過程中程序那些轉移符號不會轉換為實際的地址。二是在目標文件記錄轉移指令相關信息。
其次要明白OS裝載程序的過程。OS為了運行程序，OS loader 需要將程序裝載到內存。此時程序中每個段在內存中的位置都知道，OS loader根據程序頭(program header)中信息將程序中的轉移指令地址轉換為絕對地址。
當你運行debug調試程序時，你需要知道的是此時被調試的程序已經載入內存了，程序已經在運行了，我們只不過是用了debug的單步跟蹤功能使得執行一條指令後回到debug控制。也就是說裡面的轉移符號都已經確定為實實在在的內存地址。

明白以上幾點，需要你了解編譯原理、操作系統相關知識。當然這只是大概，具體的細節包括可執行文件結構等等需要自己細心了解。希望對你有所幫助！

⑹ c語言編譯器

目前比較流行的包括微軟的Visual C++，GCC, Turbo C等。

個人比較推薦GCC，對於初學者而言，雖然Visual C++比較快上手，它幫助開發人員快速新建工程，並添加工程相關代碼，只需要在這個平台之上直接開發代碼即可，但是這個平台把C語言的一些很關鍵的東西給省略了，例如Makefile，例如一些基本的庫函數的引用之類的。

GCC能讓開發人員從編譯器的角度出發，把程序的編譯，鏈接等一步一步都完全展示出來，而且也是建立的ANSI C的基礎上的，推薦GCC。開發者可以利用一些簡單的文本編輯器進行程序的編寫，然後通過GCC來編譯，這樣可以在起步就不收到包括Visual C++的限制，讓初學者可以更關注與整個程序的編譯過程。

當然如果說到調試方法的話，建議採用Visual C++，它提供的單步跟蹤功能確實非常好，不過在GCC下也可以用GDB進行操作，一起看個人的喜好。

⑺ 單片機，什麼叫「單步運行程序」

單步運行程序就是你的程序不是一次全部執行完所有的指令，而是一條指令執行完後暫停，然後再單步運行下一條指令，這是調試程序時的一種方法。

⑻ c語言中什麼叫做單步調試，步驟是什麼

單步調試是指程序開發中，為了找到程序的bug，通常採用的一種調試手段，一步一步跟蹤程序執行的流程，根據變數的值，找到錯誤的原因。

解決這個問題的方法如下：

1、首先需要設置斷點的那一行代碼的最前面點擊下，就會出現一個紅色的圓球，代表設置斷點成功，下圖一共設置了4個斷點。

⑼ C語言中 編譯器中F10 F9有什麼用 設置斷點只是為了監聽這個數發生 的變化

F9是編譯連接的快捷鍵。F10 是逐行單步跟蹤鍵，在某條語句調用一個函數的時候它不會進入（除非那裡設有斷點）
設置斷點不只是做這個，有時也是為了查找程序錯誤，比如看一下程序的執行過程是否運行了某段代碼等。

⑽ 看到您2009-4-29 17:54提問的關於ARM的問題，我也遇到類似的，已經折騰了幾天了，您後來是怎麼解決的啊

一般而言，如果在C語言中有對自行發生變化的變數進行條件判斷的代碼中，必須考慮編譯器對這部分代碼的「理解」。根據編譯器的不同，以及編譯器的設置，有時候你的代碼編譯器並不能完全理解，從而生成了奇怪的代碼。
在硬體編程中，通過對標志位的判斷來決定下一步的動作是很常見的。我沒有看到你的具體代碼，一般會類似於
while(1)
if( flag == 1)
break;
這樣的代碼。建議你的調試方法是，在if(flag==1)這條語句的地方設置斷點，然後進行「匯編代碼」的單步跟蹤（不同的調試開發環境有不同的方法單步跟蹤匯編指令）。如果你發現編譯器產生的代碼根本沒有重新獲取全局變數flag的值，而僅僅是判斷一下是否為1，那麼證明是編譯器曲解了你的代碼含義。還有一種情況是編譯器確實重新去獲取了全局變數flag的值，而那個值確實沒有被設置，那麼就要檢查中斷程序的代碼了。
如果是編譯器「曲解」了你那段代碼的意義，可以通過兩個方法來嘗試解決：
1，把這段函數的優化關閉。根據編譯器的不同，通知編譯器關閉對這段函數的優化的指令也不同。簡單一點可以在編譯器的全局設置上關閉對該項目的全部優化，來進行測試。當然全部關閉優化在實際產品開發上是絕對不允許的。
2，在聲明全局變數時，通知編譯器不要對這個全局變數進行優化。我沒看到你的具體代碼，但是如果你的全局變數名叫flag，類型是int，那麼可以用下面的方法來聲明：
volatile int flag;
也就是在在變數類型int之前加入一個volatile指令。這條指令對大多數ARM的C語言編譯器都是有效的。如果編譯無法通過，你可以把更詳細的信息給我，讓我看看。