c++ - 计算对C++的堆栈需求；如何获得可读的符号表？

Question

假设您不仅具有可执行文件，还具有源代码文件。

我的问题是仅针对局部变量，返回地址，传递参数来计算运行过程的正确堆栈大小。我试图使用MS开发的VMMap。因为它可以捕获具有堆栈等类别的系统中分配的内存。但是，它也包含保护页，分页文件等。因此，VMMap的堆栈大小被高估了。

我想改变解决问题的方式。我将使用WinAPI的StackWalker64跟踪堆栈以绘制实际的调用树，并从可执行文件或源代码中获取符号表。但是存在一个问题，即来自可执行文件(例如ELF)的符号表不可读。

现在，我计划使用doxygen，它是带有编译器词法分析器的开源项目。因为doxygen仅提供函数列表及其返回类型和函数参数，所以我不了解局部变量。因此，我还需要词法分析器来制作完整的符号表作为预处理。但这有点复杂。我不确定这是最佳解决方案。
有更好的解决方法吗？

Answer 1

OP想要做的是静态计算最坏情况下的堆栈深度。

这很难做到。为此，他需要:

每个函数的源代码(用作导出以下事实的原 Material )

每个函数

的“符号表”(所有声明)

跨编译单元

的应用程序代码的调用图

深入了解他的特定编译器如何生成和优化代码

“符号表”必须是编译器精确的，以便估算过程知道(从概念上)哪个声明的数据进入了堆栈。对于他特定的C++语言，OP将需要相当于一个完整的编译器前端的内容。 [OP错误地认为“词法分析器”会给他一个符号表。它不会]。

现在考虑构造全局调用图。基础看起来很简单；如果函数“bar”包含“foo(x)”，则“bar”调用“foo”。但是有很多复杂性:重载，虚函数，间接调用和强制转换。可以通过名称和类型解析来解决重载。面对模板，这会变得困惑(考虑SFINAE)。虚拟函数和间接调用迫使人们建立一个保守的指向分析器。足够丑陋的强制转换可能会强制假定对任何参数兼容函数的调用。指向分析仪的精度各不相同。低精度可能会产生带有很多假(保守)边缘的调用图，这将使尺寸估计无法进行。
编译器将不提供此全局调用图，因为它仅在单个编译单元上运行。

最后，我们可以考虑构建堆栈大小估计。在这里，我们需要了解用于表示每种声明的数据类型的大小和对齐方式，以及所需的特定编译器如何将局部变量分配给堆栈。通常，顺序编码块{....} {...}与堆栈位置重叠。还需要了解如何评估表达式以及如何传递参数，因为它们会影响堆栈的使用。最后，需要了解编译器如何分配寄存器以及编译器可以/对(did)应用哪些优化，因为这种优化将影响表达式堆栈的使用以及实际分配给堆栈的局部变量的数量。这是一个非常糟糕的知识，唯一值得信赖的知识来源就是编译器本身。与其尝试复制所有这些机制，不如让编译器提供每个函数的实际堆栈大小分配(我相信GCC会这样做)，或者放弃获得精确结果并保守估计堆栈需求，可能会更好。假设每个声明的局部变量都消耗堆栈空间(在这种情况下，不清楚应该做什么来估计表达式堆栈的使用；可能假设每个变量和中间表达式结果都根据其类型占用堆栈空间)。

通过每个函数的堆栈空间估计和一个调用图，对调用图的简单分析可以从根生成每个调用链的堆栈需求。这些最大值是所需的堆栈估计数。 (注意:这是假设每个函数在每次调用时都使用其全部堆栈需求；这显然是保守的估计)。这部分很简单。

总的来说，这是一个复杂的分析。理想情况下，您可以让编译器提供堆栈大小估计和基本调用图事实。建立指向分析很困难，并且随着应用程序规模的扩大而变得非常困难。

可以说，您可以弯曲GCC来帮助提供编译单元级别的数据。大概将Clang设计为弯曲以提供相同的数据。据我所知，它们都没有为全局指向分析提供特定支持。目前尚不清楚GCC和Clang是否处理C++的Windows方言。他们可能会。

我们的DMS软件再造工具包及其C++前端旨在提供符号表，名称解析的结果(例如，解决重载)，并且可以轻松提取本地调用事实。它处理C++的GCC和MS方言。 DMS还为建立全局指向分析和全局调用图提供支持。尽管我们还没有专门针对C++使用它，但是我们已经使用它来处理大约1600万行的C应用程序。

所有这些困难解释了为什么人们经常下注并尝试使用动态分析来查看堆栈有多大。如果OP需要静态分析仪，则他需要准备投入大量精力来获得它。