how does debugger resume from breakpoint?

Question

Assume a debugger(common x86 ring3 debugger such as olly, IDA, gdb...) sets a software breakpoint to virtual address 0x1234.

this is accomplished by replacing the whatever opcode at 0x1234 to '0xCC' now let's assume that debugee process runs this 0xCC instruction and raises software exception and debugger catches this.

debugger inspects memory contents, registers and do some stuff.. and now it wants to resume the debugee process.

this is as far as I know. from now, its my assumption.

debugger recovers the original opcode(which was replaced to 0xCC) of debugee in order to resume the execution.

debugger manipulates the EIP of debugee's CONTEXT to point the recovered instruction.

debugger handles the exception and now, debugee resumes from breakpoint.

but debugger wants the breakpoint to remain. how can debugger manage this?

Answer 1

To answer the original question directly, from the GDB internals manual:

When the user says to continue, GDB will restore the original instruction, single-step, re-insert the trap, and continue on.

Answer 2

in short and common people words:

Since getting into debug state is atomic operation in X86 and in ARM the processor gets into it and exit of debug state as same as any other instruction in the architecture. see gdb documentation explains how it works and can be used.

Here are some highlights from ARM and X86 specifications:

in ARM:

SW (Software) breakpoints are implemented by temporarily replacing the instruction opcode at the breakpoint location with a special "breakpoint" instruction immediately prior to stepping or executing your code. When the core executes the breakpoint instruction, it will be forced into debug state. SW breakpoints can only be placed in RAM because they rely on modifying target memory.

A HW (Hardware) breakpoint is set by programming a watchpoint unit to monitor the core busses for an instruction fetch from a specific memory location. HW breakpoints can be set on any location in RAM or ROM. When debugging code where instructions are copied (Scatterloading), modified or the processor MMU remaps areas of memory, HW breakpoints should be used. In these scenarios SW breakpoints are unreliable as they may be either lost or overwritten.

In X86:

The way software breakpoints work is fairly simple. Speaking about x86 specifically, to set a software breakpoint, the debugger simply writes an int 3 instruction (opcode 0xCC) over the first byte of the target instruction. This causes an interrupt 3 to be fired whenever execution is transferred to the address you set a breakpoint on. When this happens, the debugger “breaks in” and swaps the 0xCC opcode byte with the original first byte of the instruction when you set the breakpoint, so that you can continue execution without hitting the same breakpoint immediately. There is actually a bit more magic involved that allows you to continue execution from a breakpoint and not hit it immediately, but keep the breakpoint active for future use; I’ll discuss this in a future posting.

Hardware breakpoints are, as you might imagine given the name, set with special hardware support. In particular, for x86, this involves a special set of perhaps little-known registers know as the “Dr” registers (for debug register). These registers allow you to set up to four (for x86, this is highly platform specific) addresses that, when either read, read/written, or executed, will cause the processor to throw a special exception that causes execution to stop and control to be transferred to the debugger