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 ?

Bob5421
  • 7,757
  • 14
  • 81
  • 175

1 Answers1

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.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • 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... – Bob5421 Jun 16 '16 at 15:58
  • "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. – Employed Russian Jun 16 '16 at 16:08
  • 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 Jun 16 '16 at 19:25
  • @Bob5421 Code that shows how to resume from a breakpoint is [here](https://github.com/eliben/code-for-blog/blob/master/2011/debuggers_part2_code/debuglib.c#L117). It's from Eli Bendersky. The accompanying article from his blog is [How debuggers work: Part 2 - Breakpoints](http://eli.thegreenplace.net/2011/01/27/how-debuggers-work-part-2-breakpoints) – Mark Plotnick Jun 17 '16 at 14:31
  • 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 ? – Bob5421 Jun 17 '16 at 18:18
  • I have also another question/remark. In some sample programs, i see a wait(NULL) after the ptrace attach. What is the meaning of this wait ? – Bob5421 Jun 17 '16 at 19:15
  • And one more thing: how works Thread specific breakpoints ? If i replace in instruction by 0xcc, it is for all threads... – Bob5421 Jun 18 '16 at 04:47
  • That is great thanks. Do you know how it works on OS X ? I would like to say it is the same thing. ptrace sys call is existing on OS X but something is missing – Bob5421 Jun 19 '16 at 10:38