Quoted from here.
gdb puts the debugged process in its own pgrp and sets the terminal to that pgrp. (Try e.g. ps j on the PIDs of gdb and your program being debugged.)
And what does it mean by
ps j on the PIDs of gdb and your program being debugged
does that mean ps j PID?
I don't get anything special from this though...
Basically I don't understand what that article is talking about,can anyone explain it in more great details?
A “pgrp” is a process group. ps j lists the process group ID (the column is called PGID). The PGID of a process is typically itself or its parent's process group, but can be arbitrarily set with setpgid(). Process groups control what processes receive job control signals. I think gdb moves the process to its own group so as to avoid having the process receive job control signals that would mess up gdb's control over the process.
The bug report is about using gdb with a program that uses sigwait. sigwait allows a process to receive a signal in an underhand way: instead of being delivered to the process in the usual manner, the signal is removed from the pending queue and sigwait returns. This is mainly useful to arrange for a signal to be always delivered to a particular thread: block the signal, but have a thread consume it by running sigwait.
Since the signal is not actually delivered to the process, ptrace sees nothing, and so gdb isn't notified that the process has underhandedly consumed the signal.
The debate in the bug report is about whether the kernel should be modified so that ptrace sees something when the signal is consumed through sigwait, or whether gdb should handle this situation differently. I don't know enough about this to take sides.
