我正在做一个进行unix系统调用的项目。具体来说，我的项目很大程度上依赖于对getcontext（），makecontext（），swapcontext（）和setcontext（）的调用。我尝试使用gdb调试我的代码。我逐行进入代码并检查控件但是一旦调用swapcontext（），它就不再进入代码了。相反，调试几乎停在那里，程序的其余部分自动运行而不是逐行运行。我猜gdb不会进入上下文调用？有没有办法解决这个问题？有没有我可以使用的调试器？ 感谢
答案 0 :(得分：1)
setcontext和swapcontext调用会更改程序的堆栈，并且gdb会感到困惑。我不知道其他调试器是否可以很好地处理它。
答案 1 :(得分：0)
gdb逐步执行一个线程并将其调用为当前线程。其他线程将在您执行此操作时运行。如果设置的断点在当前线程以外的线程中被命中，则gdb会将当前线程更改为该线程。步进现在相对于新的当前线程。
答案 2 :(得分：0)
使用带有'step'或'next'的swapcontext（）调用gdb步进不起作用，因为不仅stackpointer更改，而且调用返回到不同的代码行（这是swapcontext（）的期望效果） 。由于gdb在下一个代码行中放置一个断点，直到另一个swapcontext（）返回到这个地方才会执行，执行不会中断。
您需要预见swapcontext（）将返回的行并在那里设置断点。对于新的（未使用的）上下文，这将是您指定为入口函数的行。对于使用过的上下文，它可能是swapcontext（）之后的一行......
答案 3 :(得分：0)
您可以重复使用GDB的stepi命令首先进入，然后单步执行swapcontext()功能。您必须执行几十次，包括内核系统调用的几个步骤 - 我假设保存浮点状态？ - 并且您最终会出现在您要交换的用户线程中。它有点耗时，但它确实有效。
答案 4 :(得分：-1)
尽管您可能不喜欢这个答案，但最好的办法是用手小部件逐步执行代码。对于像GDB和Valgrind这样的调试器，线程程序不能很好地发挥作用（至少根据我的经验），大多数错误都可以通过对代码进行仔细的逐步手动分析来确定。