假設一個調試器（常見的x86 ring3調試器，如olly，IDA，gdb等）將軟件斷點設置爲虛擬地址0x1234。調試器如何從斷點恢復？
，這是通過在0x1234的更換任何操作碼「的0xCC」 現在讓我們假設調試進程完成運行這個指令的0xCC並引發 軟件異常和調試器捕獲此。
調試器檢查存儲器內容，註冊並做一些事情..現在它想要恢復進程的debugee進程。
這是據我所知。從現在開始，這是我的假設。
調試器恢復原來的操作碼（已被替換爲0xCC） 歹徒爲了恢復執行。
調試程序操縱debugee's CONTEXT的EIP指向 恢復的指令。
調試器處理異常，現在，惡魔從斷點恢復。
但調試器希望斷點保持不變。 調試器如何管理這個？
在短期和老百姓的話：
自從進入調試狀態原子操作X86和ARM處理器進入它和調試狀態的退出是一樣的，在架構的任何其他指令。 見gdb documentation說明它是如何工作和可以使用的。
以下是ARM和X86規格的一些亮點：
在ARM：
SW（軟件）斷點被暫時處於斷點位置用特殊 更換 指令操作碼實施了「斷點「指令之前立即執行或執行 您的代碼。當內核執行斷點指令時，將會強制 進入調試狀態。 SW斷點只能放在RAM 中，因爲它們依賴於修改目標內存。
通過對觀察點單元進行編程來設置硬件（硬件）斷點，以監視從特定存儲器位置獲取指令的內核總線。 HW 斷點可以在RAM或ROM中的任何位置設置。在調試 指令被複制（Scatterloading），修改或處理器MMU重新映射內存區域的代碼時，應使用HW斷點。 在這些情況下，SW斷點不可靠，因爲它們可能是 丟失或被覆蓋。
在X86：
方式軟件斷點的工作是相當簡單的。具體來說，要設置一個軟件斷點，調試器只需在目標指令的第一個字節上寫入一個int 3指令（操作碼0xCC）即可，即 。當執行 被轉移到您設置斷點的地址時，會導致中斷3被觸發。當這個 發生時，當您設置 斷點時，調試器「插入」並將0xCC操作碼字節與 交換指令的原始第一個字節，以便您可以立即繼續執行，而不必立即觸擊相同的斷點。實際上有更多的魔力 涉及，允許您從斷點繼續執行，並且 不立即命中，但保持斷點處於活動狀態以供將來使用; 我會在以後的文章中討論這個問題。
硬件斷點，正如你可能想象到的名字，設置 與特殊的硬件支持。特別是，對於x86，這涉及到一個特殊的可能鮮爲人知的寄存器組，稱爲「Dr.」 寄存器（用於調試寄存器）。這些寄存器允許您設置最多 四個（對於x86，這是高度特定於平臺的）地址，當 讀取，讀取/寫入或執行時，會導致處理器向 發送導致執行停止的特殊異常和控制 轉移到調試
直接回答原來的問題，從GDB internals manual：
當用戶說繼續，GDB會恢復原來的 指令，單步，重新插入陷阱，然後繼續。
好問題。我猜測片上調試器支持硬件必須幫助解決這個問題。 – 2013-03-26 18:04:33