/Z7
、、 /Zi
/ZI
(偵錯資訊格式)
/Z7
、 /Zi
和 /ZI
編譯器選項會指定為程式建立的偵錯資訊類型,以及此資訊是否保留在物件檔或程式資料庫 (PDB) 檔案中。
語法
/Z7
/Zi
/ZI
備註
當您指定偵錯選項時,編譯器會產生函式和變數、類型資訊和行位置的符號名稱,以供偵錯工具使用。 這個符號偵錯資訊可以包含在編譯器所產生的物件檔( .obj
檔案)中,或包含在可執行檔的個別 PDB 檔案中。 .pdb
下列各節將說明偵錯資訊格式選項。
無
根據預設,如果未指定偵錯資訊格式選項,編譯器不會產生偵錯資訊,因此編譯速度會更快。
/Z7
選項 /Z7
會產生物件檔,其中包含與偵錯工具搭配使用的完整符號偵錯資訊。 這些物件檔案和從它們建置的任何程式庫,可以大大大於沒有偵錯資訊的檔案。 符號偵錯資訊包含變數、函式和行號的名稱和類型。 編譯器不會產生 PDB 檔案。 不過,如果連結器已傳遞 /DEBUG
選項,仍然可以從這些物件檔或程式庫產生 PDB 檔案。
對於協力廠商程式庫偵錯版本的散發者來說,沒有 PDB 檔案是有好處的。 不過,在程式庫連結階段和偵錯期間,需要任何先行編譯標頭的物件檔。 如果物件檔中 .pch
只有類型資訊(且沒有程式碼),您也必須在建置程式庫時,使用預設啟用的 /Yl
[插入偵錯程式庫的 PCH 參考] 選項。
指定時 /Z7
,無法使用已取代 /Gm
的 [啟用最小重建] 選項。
/Zi
此選項 /Zi
會產生個別的 PDB 檔案,其中包含與偵錯工具搭配使用的所有符號偵錯資訊。 偵錯資訊不會包含在物件檔或可執行檔中,因此小得多。
的使用 /Zi
不會影響優化。 不過, /Zi
確實暗示 /debug
。 如需詳細資訊,請參閱 /DEBUG
(產生偵錯資訊)。
當您同時 /Zi
指定 和 /clr
時, DebuggableAttribute 屬性不會放在元件中繼資料中。 如果您想要的話,您必須在原始程式碼中指定它。 這個屬性可能影響應用程式的執行階段效能。 如需屬性如何影響 Debuggable
效能以及如何修改效能影響的詳細資訊,請參閱 讓影像更容易偵錯 。
編譯器會將 PDB 檔案 <project>.pdb
命名為 ,其中 <project>
是專案的名稱。 如果您在專案外部編譯檔案,編譯器會建立名為 VC<x>.pdb
的 PDB 檔案,其中 <x>
是使用中編譯器版本的主要和次要版本號碼串連。 編譯器會在使用此選項建立的每個物件檔案中內嵌 PDB 的名稱和識別時間戳記簽章。 這個名稱和簽章會將偵錯工具指向符號和行號資訊的位置。 PDB 檔案中的名稱和簽章必須符合可執行檔,才能在偵錯工具中載入符號。 WinDBG 偵錯工具可以使用 命令載入不相符的 .symopt+0x40
符號。 Visual Studio 沒有載入不相符符號的類似選項。
如果您從使用 /Zi
編譯的物件建立程式庫,當程式庫連結至程式時,必須提供相關聯的 PDB 檔案。 這表示,如果您發佈程式庫,您也必須散發 PDB 檔案。 若要建立包含偵錯資訊的程式庫,而不使用 PDB 檔案,您必須選取 /Z7
選項。 如果您使用先行編譯標頭選項,則先行編譯標頭和其餘原始程式碼的偵錯資訊會放在 PDB 檔案中。
/ZI
選項 /ZI
類似于 /Zi
,但它會產生支援 [編輯後繼續 ] 功能格式的 PDB 檔案。 若要使用 [編輯後繼續偵錯] 功能,您必須使用此選項。 [編輯後繼續] 功能對於開發人員生產力很有用,但可能會導致程式碼大小、效能和編譯器一致性的問題。 因為大部分的優化與編輯和繼續不相容,因此使用 /ZI
會停用 #pragma optimize
程式碼中的任何語句。 選項 /ZI
也與使用 __LINE__
預先定義的宏 不相容;使用 編譯 /ZI
的程式碼無法當做非類型樣板引數使用 __LINE__
,不過 __LINE__
可用於宏擴充。
選項 /ZI
會 /Gy
強制在編譯中使用 [啟用函式層級連結] 和 /FC
[診斷中原始程式碼檔案的完整路徑] 選項。
/ZI
與 /clr
[Common Language Runtime 編譯] 不相容。
注意
此選項 /ZI
僅適用于以 x86 和 x64 處理器為目標的編譯器。 此編譯器選項不適用於以 ARM 處理器為目標的編譯器。
在 Visual Studio 開發環境中設定這個編譯器選項
開啟專案的 [屬性頁] 對話方塊。 如需詳細資料,請參閱在 Visual Studio 中設定 C ++ 編譯器和組建屬性。
選取 [ 組態屬性 > C/C++ > 一般 ] 屬性頁。
修改 [ 偵錯資訊格式] 屬性。 選取 [確定] 儲存您的變更。
若要以程式方式設定這個編譯器選項
另請參閱
意見反映
https://aka.ms/ContentUserFeedback。
即將推出:我們會在 2024 年淘汰 GitHub 問題,並以全新的意見反應系統取代並作為內容意見反應的渠道。 如需更多資訊,請參閱:提交及檢視以下的意見反映: