如何确保在优化过程中不删除局部变量

How to ensure local variables are not removed during optimization

本文关键字：过程中 优化 删除 局部变量 何确保 确保      更新时间：2023-10-16

背景

在工作中，我经常使用优化代码的核心转储进行死后调试。

对于某些类型的难以再现的故障，我希望获得额外的信息。在这种情况下，添加额外的跟踪是不可行的，因为绝大多数调用都是成功的，并且每分钟会添加数百万个"不必要"的跟踪，这将快速滚动日志文件。捕获和跟踪并不总是可行的，因为一些错误可能会破坏环境，导致跟踪失败。

由于我们的核心转储包括调用堆栈内存，我想我可以使用调用堆栈内存上的一个区域进行"跟踪"。

问题

多亏了优化编译器，像这样的代码不起作用

void process (int i)
{
   int save_me = i;
   // Do something else
}

其思想是通过分配给局部变量来将输入变量存储在堆栈上。这通常在调试模式下运行良好，但在优化的构建中，编译器认为该语句没有副作用并将其删除

alloca似乎可以工作，但我们针对的是一些不支持alloca的平台，我不确定它与C++的配合效果如何。

我做了一些实验，以下代码似乎能够使状态"停留"在堆栈上，即使在优化的构建中也是如此：

#include <cstdint>
#include <stdexcept>
#include <istream>
#include <sstream>
struct saved_state
{
  saved_state ()
    : head  (0xAABBCCDD)
    , tail  (0xEEFF0000)
  {
    std::fill (state, state + 16, 0);
  }
  void push (std::int32_t input) volatile
  {
    for (auto i = 15U; i > 0U; --i)
    {
      state[i] = state[i - 1];
    }
    state[0] = input;
  }
  volatile std::uint32_t  head      ;
  volatile std::int32_t   state [16];
  volatile std::uint32_t  tail      ;
};
void invoke (std::int32_t i)
{
  if (i > 10)
  {
    throw std::runtime_error ("Busted");
  }
}
void process (std::istream & input)
{
  saved_state volatile ss;
  while (!input.eof ())
  {
    std::int32_t i;
    if (input >> i)
    {
      ss.push (i);
      invoke (i);
    }
  }
}
int main()
{
  std::istringstream input ("1n2n30n");
  process (input);
  return 0;
}

问题

我可以期望代码执行我希望它执行的操作吗？它似乎适用于我们当前的编译器集(clang&gcc(，但我能指望它继续工作吗？

有没有更好的方法来实现我想要做的事情？

我所说的"更好"是指更简单、更健壮或符合标准。

从您的问题中可以看出，您知道在代码的特定函数/区域中存在罕见/难以调试的问题？我之所以这么认为，是因为你在谈论手动仪器，我猜你不打算在任何地方都这样做，因为你预计会出现可能的问题。

如果这是您的情况，那么我认为您可能需要考虑仅禁用该函数/代码区域的优化。在Visual Studio中，您可以使用#pragma来实现这一点，我想clang/gcc也存在类似的功能。在最坏的情况下，您可以将相关函数提取到一个单独的文件中，然后只编译该文件而不进行优化。

这可能对那些只出现在优化构建中的问题没有帮助，但当你遇到那些棘手的Heisenbug时，任何类型的添加跟踪都可能会隐藏issue或使其不那么频繁。在这种情况下，你唯一真正的办法就是真正擅长破译拆解。。。

也就是说，volatile确实告诉编译器，它不允许优化读写，因此您的方法应该是稳健的，并且可能是解决某些类型错误的有用工具。

优化的编译可能很难调试：

你可以试试这样的东西：

在您的示例中：

void process (int i)
{
   int save_me = i;
   // Do something else
}

(预初始化的(形式参数和auto变量都在同一个堆栈上，只相隔几个字节。如果在"做其他事情"期间发生崩溃，优化器已经对不再使用的堆栈项进行了处理。

我运气不错的是：

void process (int i)
{
   // Do something else
   if (bool_that_compiler_can_not_predetermine_is_always_false)
   {
       std::cerr << "error:  int i is " << i << std::endl;
   }
}

由于编译器无法确定cerr行永远不会被执行，因此它将生成代码，并将形式参数保留在作用域中。

当然，除了cerr，你还可以选择其他动作。也许是日志条目？也许是更小的。关键是，在丢弃i的值(或者，如果您仍然需要save_me(之后，直到"进程"结束，核心转储中的故障才可能发生。

优化器也可以重新排序代码，但if子句在进程末尾的位置(我认为(迫使do的所有部分在该子句之前完成其他操作。

我有时会使用时间戳来创建cannot be true子句。(因为：：time(0(非常有效(。

如果您有一个main，argc很容易使用，即(0==argc(或(argc>100(，并且多余的args很容易被忽略。

相关文章：