使用用户定义或 python 命令序列的 C++ 线程不会在 gdb 异步模式下停止

我在嵌入式 powerpc 目标上使用 gdb 7.4.1 对使用 pthread 的多线程 C++ 程序执行一些分析。我的最终目标是使用 python 编写 gdb 脚本来自动化一些常见的分析功能。问题是，当我单独运行命令与在 gdb 用户定义的命令（或通过 python 脚本调用相同的命令）中运行命令时，我发现行为存在一些差异。

编辑：我发现this http://sourceware.org/ml/gdb/2009-01/msg00154.html参考主 gdb 邮件列表上的一个非常相似的问题。虽然我不完全遵循 Pedro 关于异步模式限制的回应，但我认为他暗示在异步模式下，用户定义的命令序列的相对时间不可信。这是我凭经验发现的。

在这两种情况下，我都会执行以下启动步骤，加载程序，设置其参数，打开异步和不间断调试模式，然后在后台运行程序：

(gdb) file myprogram
(gdb) set args --interface=eth0 --try-count=0
(gdb) set target-async on
(gdb) set pagination off
(gdb) set non-stop on
(gdb) run &

此时，如果我手动发出interrupt进而info threads命令时，我看到所有正在运行的线程的列表（除了已停止的线程之外）。那我就可以continue &并让我心满意足地重复一遍，它始终有效。当停止时，我可以检查该线程的堆栈帧，一切都很好。

但是，如果我将这些命令放入用户定义的 gdb 命令中：

(gdb) define foo
(gdb) interrupt
(gdb) info threads
(gdb) continue &
(gdb) end
(gdb) foo
Cannot execute this command while the selected thread is running.

然后 foo 打印的线程列表表明没有线程被停止，所以continue &命令返回Cannot execute this command while the selected thread is running.。我认为这是异步 gdb 命令固有的问题，因此我在中断命令后插入了一个荒谬的长时间等待，并得到了相同的行为：

(gdb) define foo
(gdb) interrupt
(gdb) shell sleep 5
(gdb) info threads
(gdb) continue &
(gdb) end
(gdb) foo
Cannot execute this command while the selected thread is running.

无论有没有 sleep 命令，我始终可以发出手动 CLI 命令并且线程会正确停止。

同样，我通过使用 python 脚本来进行线程细读，得到了相同的结果：

import gdb, time

gdb.execute("file myprogram")
gdb.execute("set args --interface=eth0 --try-count=0")
gdb.execute("set target-async on")
gdb.execute("set pagination off") 
gdb.execute("set non-stop on")
gdb.execute("run &")
time.sleep(5)
gdb.execute("interrupt")

# here, I inspect threads via gdb module interface
# in practice, they're always all running bc the program neven got interrupted
for thread in gdb.selected_inferior().threads():
    print thread.is_running(),

gdb.execute("continue &")

即使我指定，我也会得到相同的结果from_tty=True in the gdb.execute来电。另外，如果我使用continue -a它会抑制错误字符串，但不会有任何帮助，因为中断调用仍然不起作用。

那么...是这样的：

• 驾驶舱错误？鉴于我想要实现的目标，是否有什么我遗漏或做得不正确的事情？这应该有效吗，还是我必须使用 GDB/MI 来像这样异步“驱动”gdb？
• 时间问题？也许调用shell sleep (or python time.sleep()）在这种情况下并没有像我想象的那样做。
• 我的 pthreads 使用有问题吗？我假设由于使用手动 gdb 命令总是可以正常工作，但事实并非如此。
• gdb问题？

Thanks.

我认为这很可能是 gdb 问题。我对劣质控制的了解还不够，所以无法更有信心。我确实知道较差的控制通常还没有连接到Python......

值得尝试的一件事是使用一个单独的 Python 线程来执行等待，然后使用 gdb.post_event 向主 gdb 线程发送“中断”命令。

然后，不要同步检查线程或在“中断”后执行工作，而是使用 gdb.events.stop 事件源来触发您的操作。

请慷慨地提交有关 Python API 中漏洞的错误。