How does GDB restore instruction after breakpoint

后端 未结 1 390
悲哀的现实
悲哀的现实 2021-01-14 11:05

I have read that GDB puts a int 3 (opcode CC) at the wanted adress in the target program memory.

Si this operation is erasing a piece of instruction (1 byte) in the

1条回答
  •  孤城傲影
    2021-01-14 11:45

    How and When GDB replaces the original opcode when the program continues ?

    I use this as an interview question ;-)

    On Linux, to continue past the breakpoint, 0xCC is replaced with the original instruction, and ptrace(PTRACE_SINGLESTEP, ...) is done. When the thread stops on the next instruction, original code is again replaced by the 0xCC opcode (to restore the breakpoint), and the thread continued on its merry way.

    On x86 platforms that do not have PTRACE_SINGLESTEP, trap flag is set in EFLAGS via ptrace(PTRACE_SETREGS, ...) and the thread is continued. The trap flag causes the thread to immediately stop again (on the next instruction, just like PTRACE_SINGLESTEP would).

    When i type disassemble in GDB, i do not see CC opcode. Is this because GDB knows it is him that puts the CC ?

    Correct. A program could examine and print its own instruction stream, and you can observe breakpoint 0xCC opcodes that way.

    Is there a way to do a raw disassemble, in order to see exactly what opcodes are loaded in memory at this instant ?

    I don't believe there is. You can use (gdb) set debug infrun to observe what GDB is doing to the inferior (being debugged) process.

    What i do not understand in fact is the exact role of SIGTRAP. Who is sending/receiving this signal ? The debugger or the target program?

    Neither: after PTRACE_ATTACH, the kernel stops the inferior, then notifies the debugger that it has done so, by making debugger's wait return.

    I see a wait(NULL) after the ptrace attach. What is the meaning of this wait?

    See the explanation above.

    Thread specific breakpoints?

    For a thread-specific breakpoint, the debugger inserts a process-wide breakpoint (via 0xCC opcode), then simply immediately resumes any thread which hits the breakpoint, unless the thread is the specific one that you wanted to stop.

    0 讨论(0)
提交回复
热议问题