在gdb中设置应用程序亲和性

Question

在不锁定gdb到同一核心的情况下，有没有简单的方法来设置我正在调试的应用程序的亲和性？我之所以问这个问题是因为该应用程序正在以实时优先级运行，并且需要在单个核心上运行。目前，我使用以下命令行：

taskset -c 3 gdbserver :1234 ./app.out

但是应用程序停止响应并冻结gdb服务器，使得调试变得不可能。我怀疑应用程序的实时优先级阻止了gdb的执行。如果我启动应用程序，然后在不设置亲和性的情况下启动gdb，那么我就可以附加并调试应用程序，而不会导致gdb冻结。

有没有一种简单的方法来使用不同的亲和性启动gdb和应用程序？或者更好的选择：是否有一个gdb命令来设置子进程的亲和性？

- Marcus Ahlberg

Answer 1

我曾经遇到类似的问题，并从你的问题中获得启发，找到了解决方案。正如你所怀疑的那样，可能是因为应用程序的一个线程占用了所有核心的周期，而gdbserver由于优先级太低而无法运行，导致其冻结。

对于我的特定需求，我正在使用gdb进行实时调度应用程序的调试，该程序在本地机器上运行，我不介意gdb在同一核心上运行，但我希望能够以所有应用程序线程的优先级进行调试。对我来说，让事情起作用的是将gdb命令扩展到这个更复杂的结构：

taskset -c 3 chrt 99 gdb

chrt命令添加到您的taskset命令中，切换到SCHED_RR策略，并以指定的优先级运行gdb。 我正在调试的线程以较低的优先级运行，因此我认为它们只在gdb未运行时运行。

我之前遇到了一个问题。 我认为，在请求gdb在断点处或其他位置暂停执行后恢复执行时，一个线程会在更高优先级的线程恢复之前开始运行，因此实际上正在运行的不一定是我期望运行的线程。 对我来说，上述命令似乎可以解决所有问题--我认为这是因为应用程序线程只能在gdb完成所有需要做的工作以便恢复程序之后才能运行。 所以，如果您想尝试这个命令，适用于您情况的命令行将是：

taskset -c 3 chrt 99 gdbserver :1234 ./app.out

注意：这样会将gdbserver锁定到某个核心，但是您的实时线程可能会以较低的优先级运行，因此gdbserver不会冻结。

- Craig Scratchley

---

这是你的答案，对我也最终起作用了 Linux不尊重SCHED_FIFO优先级？（正常或GDB执行）。 - NGI

Answer 2

我找到了一个解决方案：使用--wrapper参数。

http://sourceware.org/gdb/onlinedocs/gdb/Server.html

gdbserver --wrapper taskset -c 3 -- :1234 ./app.out

- Marcus Ahlberg

---

在gdb中执行以下命令：set exec-wrapper taskset -c 3。该命令的作用是将程序运行时绑定到CPU核心3上。 - Marcus Ahlberg