旧GDB脚本中堆栈跟踪的停止条件

Question

我有一个遗留的GDB命令脚本，用于根据python2.6源代码附带的GDB脚本获取Python堆栈跟踪（因此不允许超链接，但以下是URL:http://#%20http://svn.python.org/view/*checkout*/python/branches/release26-maint/Misc/）

脚本有一个while循环，它基于退出的程序计数器有一个相当脆弱的检查，它（如注释中的原始代码中所指出的）可能只适用于如果您直接运行Python，而不是在C/C++应用程序中启动解释器的话。在

现有的while循环如下所示：

while $pc < Py_Main || $pc > Py_GetArgcArgv
    # ...
    # code for extracting Python stack from local vars in relevant frames
    # of C stack
    # ...

    up-silently 1

对于我要调试的程序，针对Py_Main和Py_GetArgcArgv的检查不会很好地工作，所以我正在寻找一个循环条件，当它到达main时，它的值将为false。在

所以我一直在考虑使用程序计数器、帧指针和堆栈指针，因为如果up-silently失败，它们将具有与以前相同的值，这意味着我处于堆栈的顶部，如下所示：

^{pr2}$

我认为这应该能达到目的，初步检查表明它工作良好。然而，我对编译器能做的优化不是太熟悉，我担心在堆栈中间的某个地方，它们可能确实是相同的。在

对于帧指针已优化的调用（例如，通过使用GCC使用-g -O3进行编译），似乎$fp可以为零。我也不确定是否可以依赖$pc不同，尤其是在递归调用发生的情况下。我希望$sp在仍有有效堆栈要处理时会有所不同，但我有一个模糊的怀疑，即与{a1}相关的优化可能会导致$sp相同。在

如有任何建议，将不胜感激。在

具体问题：

问题1:在遗留（非Python）GDB脚本中，是否有更好的方法来判断您是否处于堆栈的顶部？在

问题2:我对$sp、$pc和{}的假设是否适用于大多数或所有优化方案？在

Answer 1

所以我对问题1没有答案，但我想我可以部分地回答问题2。在

Tail recursion确实将重用现有的堆栈指针和帧指针。对于堆栈跟踪来说，这意味着对同一优化的tail递归函数的多个调用只会在GDB中出现一次，因为（显然）堆栈指针正在被重用（而且没有新的堆栈或帧指针被压入）。在

这似乎意味着您可以对照$sp以前和当前的值来检查停止条件。不幸的是，$sp值在堆栈中间可能是相同的。当某些函数调用被优化掉时，似乎会发生这种情况。在

因此，我在问题中提出的停止条件可能相当脆弱，尽管它适用于几个真实世界的例子。在