In a debugging session, when the deugger wants to set a breakpoint, it replaces an instruction by int3. When the Target process reach this instruction, the process stops. I have read that a signal is send at this time. But i did not manage to capture this signal (i wrote my own mini debugger for testing). Who send this signal ? The kernel? And who is the receiver? I had to put a wait() fonction juste after the ptrace_cont. Do you think this is this wait function that catch the signal in order to notify the debugger that the process reach a break point ?
Asked
Active
Viewed 424 times
1 Answers
1
When the Target process reach this instruction, the process stops.
That's not quite accurate. When the trap instruction (0xCC on x86) is executed, the processor notifies the OS. On UNIX, the OS checks to see whether the process is being ptraced by somebody.
If no, the SIGTRAP signal is delivered to the application, which usually results in process being killed (but you can catch and handle the signal in the application).
If there is a ptraceer (usually a debugger), then the signal is not delivered to the application. Instead, debugger's wait is unblocked to notify the debugger that the inferior has changed state. The debugger then looks at where the inferior process stopped, discovers that it did so because of a breakpoint, and handles the situation as appropriate (let's you examine the inferior, or resumes it if the breakpoint is conditional and current conditions don't match, etc.)
Employed Russian
- 199,314
- 34
- 295
- 362