GDB如何在断点之后恢复指令 [英] How does GDB restore instruction after breakpoint
问题描述
我读过GDB把一个int 3（操作码CC）放在目标程序存储器中想要的地址处。
这个操作正在擦除一条指令（1个字节）存储在程序存储器中。
我的问题是：当程序继续时，GDB如何以及何时替换原始操作码？
当我在GDB中反汇编时，我看不到CC操作码。这是因为GDB知道他是CC吗？
有没有办法做一个原始反汇编，以便准确地看到在这个瞬间内存中加载了哪些操作码？
当程序继续时，GDB如何替换原始操作码？
作为一个采访问题; - ）
在Linux上，要继续经过断点， 0xCC 被替换为原始指令，并完成 ptrace（PTRACE_SINGLESTEP，...）。当线程在下一条指令停止时，原始代码再次被 0xCC 操作码替换（以恢复断点），并且线程继续其快乐方式。
在没有 PTRACE_SINGLESTEP 的x86平台上，陷阱标记通过 ptrace（PTRACE_SETREGS，...） EFLAGS 中设置c $ c>，线程继续。陷阱标志导致线程立即再次停止（在下一条指令中，就像 PTRACE_SINGLESTEP 会）。
当我在GDB中反汇编时，我没有看到CC操作码。这是因为GDB知道他是CC吗？
正确。一个程序可以检查和打印自己的指令流，并且可以通过这种方式观察断点 0xCC 操作码。
有没有办法做一个原始的反汇编，以便准确地看到在这个瞬间内存中加载了哪些操作码？
我不相信有。你可以使用（gdb）设置debug infrun 来观察GDB对下级进程（正在调试）的处理过程。
< blockquote>
我其实不了解的是SIGTRAP的确切作用。谁在发送/接收此信号？调试器或目标程序？
在 PTRACE_ATTACH 之后， kernel 阻止劣势，然后通过调试器的 wait 返回来通知调试器它已经这样做了。
我在ptrace附加后看到一个等待（NULL）。这个等待是什么意思？
请参阅上面的解释。
线程特定的断点？
对于线程特定的断点，调试器插入一个进程范围的断点（通过 0xCC opcode），那么只需立即恢复任何碰到断点的线程，除非线程是你想要停止的特定线程。
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 program memory. My question is: How and When GDB replaces the original opcode when the program continues ?
When i type disassemble in GDB, i do not see CC opcode. Is this because GDB knows it is him that puts the CC ? Is there a way to do a raw disassemble, in order to see exactly what opcodes are loaded in memory at this instant ?
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.
这篇关于GDB如何在断点之后恢复指令的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
