多個調試程序關閉一個斷點

Question

有沒有人見過多個調試程序錯誤地獲取行號或者是否有一個斷點？

我有一個MULTI腳本（scripty.rc），它經歷了一個過程，該過程依賴於在此程序結束時觸發一個斷點。該程序完成在兩個迴路中的一種：

:failure 
6648 NOP 
6649 b failure ; You are a failure 

:complete 
6650 NOP 
6651 b complete ; Your program worked, rejoice 

所以我應該在6649或6651突破，爲用戶打印就行了，讓他們驗證一切是hunkydory。

但是。

這不是在6651打破。至少不總是。在午餐之前，我確保一切正常，我看到它就像我想要的那樣。午飯後，當我和硬漢一起演示時，它打印的行是6650 NOP。像什麼鬼？真？我演示你的那一刻你背叛了我？

我確認軟件是一樣的，它不是一些鬼鬼祟祟的提交。

我驗證腳本是一樣的。這不像是一個不同的斷點正在設置。

我用斷點做數學。在腳本中它是bp _start#2135，是的，_start是4516.是的，經過一些深入分析，4516 + 2135 = 6651。

而且我看到它早些擊中了正確的路線。

我很想把這一個粉筆寫上與MULTI不健康的關係。解決方法很簡單，但一個非確定性的調試器聽起來很可怕，我想運行它。有沒有人見過多調試器錯誤的行號或斷點一個？任何人有任何想法，它可能是什麼？我搞砸了一些簡單的東西嗎？

Answer 1

我發現了這一個。這確實很愚蠢和簡單。

這就是MULTI的工作原理。當你設置一個斷點時，它會以procedure#123的形式記錄它。 123是程序開始時的偏移量。這個可愛的工具是用ASM編寫的，因此只有一個_start。

MULTI計數從1開始的程序行。看看MULTI調試器的左側。這也在幫助文件中以及「MULTI：Debugging Source Pane」中。最左邊一列數字是文件行號。右邊的是「程序相關行號」。

因此，破壞proc#1在程序行號+1處沒有突破，它在程序的第一行破壞。這不是一個抵消。我沒有打破4516 + 2135，而是想在4516 + 2136指令上突破。我不知道b _start#0會做什麼。

還有一個重要的教訓，就是在填寫錯誤報告和在這裏提出問題時不要懶惰。上面我輸入了行號，但省略了程序編號，認爲它們不重要。