3

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 ?

Improve this question

1 Answer 1

Reset to default
5

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

8 Comments

Thanks, but i do not understand who replace this flag. In order to understand this mechanism i would like to write a small program in C that pthread_atach, put a breakpoint and do the something than GDB but i do not know how to do...
"I do not understand how to set TF flag" -- take a look at man ptrace, PTRACE_SETREGS. Also I missed PTRACE_SINGLESTEP, which is what is actually used on Linux and is much simpler. Updated the answer.
Can you give me a piece of C code that do the same thing than gdb ? Suppose i've already attach the process. Thanks
@Bob5421 Code that shows how to resume from a breakpoint is here. It's from Eli Bendersky. The accompanying article from his blog is How debuggers work: Part 2 - Breakpoints
Thanks i have ready this article yesterday. 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 ?
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.