GDB调试时遇到sigwait阻塞的解决办法

gdb调试，遇到sigwait函数，就无法继续运行下去，如同中断一般，却又无法通过C-c停止调试。

其实，只要给程序发送一个信号，让他接受到信号就可以了，比如：kill -2 [进程号] （-2是SIGINT信号）

参考外文：

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

When you hit C-c, the signal goes to the current pgrp, i.e. to the debugged process and not to gdb.  When a signal is delivered, ptrace will intercept it and let gdb decide what to do before it actually reaches the debugged process.  Unless you are using "handle SIGINT nostop", then gdb will stop and give you a prompt here.

However, your program uses sigwait and so the signal is never actually delivered.  Instead, you dequeue it via sigwait without going through actual signal delivery.  ptrace only reports a signal that is about to be delivered.  When you use sigwait, technically the signal is blocked the whole time and never delivered as such.  The fact that ptrace does not report this signal is the expected behavior.

It could indeed be useful to let debuggers intercept signals being dequeued by sigwait.  But, it would be wrong to change the existing ptrace interface to report these the same way it reports signals being dequeued for delivery.  The existing ptrace indication of a signal says that the reporting thread will run the handler or default action, and that is what debuggers now expect that it means.  Using the same report for a signal that was swallowed by sigwait could confuse existing debuggers.  A report may be desireable, but it will have to be requested differently from the existing vanilla ptrace signal case.

For your situation, you are not really interested in the sigwait reporting per se.  What you have asked for is to get a terminal signal to wake up gdb.  That is entirely doable within gdb's domain already.  You might be able to get it to happen by using gdb's "attach" and/or "tty" commands.  If not, that is an issue with gdb that you can try to get fixed.  If it provides some way to interrupt gdb that does not involve any signals generated for the debugged process, you are fine.  It could do that by not changing the pgrp of gdb's controlling tty so that a C-c sends SIGINT to gdb and not to the debugged process, or by giving some other means to wake up gdb.  (To avoid changing gdb's ctty's pgrp, you'd have to use a different tty for the debugged process if it does any terminal i/o of its own.)