我在嵌入式powerpc目标上使用gdb 7.4.1对我使用pthreads的多线程C++程序进行一些分析.我的最终目标是使用python编写脚本gdb以自动执行一些常见的分析功能.问题是,当我单独运行命令而不是gdb用户定义的命令(或通过python脚本调用相同的命令)时,我发现行为有些不一致.
编辑:我发现这个引用非常类似的问题主要gdb的邮件列表上.虽然我没有完全遵循Pedro关于异步模式限制的回应,但我认为他暗示在异步模式下,用户定义的命令序列的相对时序是不可信任的.这是我凭经验找到的.
在这两种情况下,我执行以下启动步骤,加载程序,设置其args,打开异步和不间断调试模式,然后在后台运行程序:
(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) …在分布式 yocto 构建环境中，通过 NFS 在繁忙的构建节点上托管全局状态缓存（通过 SSTATE_MIRRORS）是一个坏主意吗？
我最近在 yocto 构建配置中引入了 SSATE_MIRRORS，以尝试进一步减少“构建节点”（vSphere 中的 Jenkins 代理和开发人员工作站）上的 yocto 构建时间。根据手册，如果在本地 sstate 缓存 (SSTATE_DIR) 中找不到已构建的工件，yocto 将在 SSATE_MIRRORS 中搜索它们。
所有构建节点都有一个本地 SSATE_DIR，它们在其中缓存构建结果。其中一个构建节点（第一个 Jenkins 代理）被指定为“全局缓存的守护者”，并将其本地 SSTATE_DIR 导出为 ar/o NFS 共享。其他构建节点安装它，并在其构建配置中通过 SSATE_MIRRORS 引用它。我想我有一个非常好的主意，并拍拍自己的背。
唉，我发现进行更改后构建时间显着增加。
当然，在得出任何结论之前，我需要做很多故障排除和测量工作。我们正在使用 NFS v4，并且肯定需要在那里进行调整。另外，我怀疑托管 NFS 共享的构建节点间歇性地非常忙于执行 yocto 构建本身（填充其混合本地/全局缓存），为内核留下很少的 CPU 周期来管理 NFS 请求。
我想知道其他人是否可以根据他们实现共享 yocto 状态缓存的经验提供建议。