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 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
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.