为什么 64 位 VC++ 编译器在函数调用后添加 nop 指令？

Question

我使用 Visual Studio C++ 2008 SP1，x64C++ 编译器编译了以下内容：

我很好奇，为什么编译器会在那些 calls 之后添加那些 nop 指令？

PS1。我知道第二个和第三个 nops 将在 4 字节边距上对齐代码，但第一个 nop 打破了这个假设。

PS2。编译的 C++ 代码中没有循环或特殊优化内容：

CTestDlg::CTestDlg(CWnd* pParent /*=NULL*/)
    : CDialog(CTestDlg::IDD, pParent)
{
    m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME);

    //This makes no sense. I used it to set a debugger breakpoint
    ::GdiFlush();
    srand(::GetTickCount());
}

PS3。 附加信息： 首先，感谢大家的意见。

以下是补充意见：

1. 我的第一个猜测是incremental linking 可能与它有关。但是，项目的Visual Studio 中的Release 构建设置关闭了incremental linking。

2. 这似乎只影响x64 构建。以x86（或Win32）构建的相同代码没有nops，即使使用的指令非常相似：

1. 我尝试使用更新的链接器构建它，尽管VS 2013 生成的x64 代码看起来有些不同，但它仍然在一些nops 之后添加了nops：

4. 另外dynamic 与static 链接到MFC 对nops 的存在没有影响。这是使用VS 2013 动态链接到 MFC dll 构建的：

5. 还要注意那些nops 也可以出现在near 和far calls 之后，它们与对齐无关。这是我从IDA 获得的部分代码，如果我再往前走一点：

如您所见，nop 插入在 far call 之后，恰好“对齐”B 地址上的下一个 lea 指令！如果这些只是为了对齐而添加的，那是没有意义的。

6. 我最初倾向于相信，因为nearrelativecalls（即以E8开头的那些）是somewhat faster而不是farcalls（或以calls开头的那些） FF,15 在这种情况下）

链接器可能会先尝试使用nearcalls，因为这些比farcalls 短一个字节，如果成功，它可能会用nops 填充剩余空间在末尾。但是上面的例子（5）有点推翻了这个假设。

所以我仍然没有明确的答案。

Answer 1

这纯粹是一种猜测，但它可能是某种 SEH 优化。我说 优化 因为 SEH 似乎在没有 NOP 的情况下也能正常工作。 NOP 可能有助于加快展开。

在以下示例 (live demo with VC2017) 中，在调用 basic_string::assign 后插入了一个 NOP test1 但不在 test2 中（相同但声明为非抛出^1)。

#include <stdio.h>
#include <string>

int test1() {
  std::string s = "a";  // NOP insterted here
  s += getchar();
  return (int)s.length();
}

int test2() throw() {
  std::string s = "a";
  s += getchar();
  return (int)s.length();
}

int main()
{
  return test1() + test2();
}

组装：

test1:
    . . .
    call     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign
    npad     1         ; nop
    call     getchar
    . . .
test2:
    . . .
    call     std::basic_string<char,std::char_traits<char>,std::allocator<char> >::assign
    call     getchar

请注意，MSVS 默认使用/EHsc 标志（同步异常处理）进行编译。如果没有该标志，NOPs 就会消失，而使用/EHa（同步和异步异常处理），throw() 将不再有任何区别，因为 SEH 始终处于打开状态。

---

¹ 出于某种原因，只有throw() 似乎减少了代码大小，使用noexcept 会使生成的代码更大，并召唤更多NOPs。 MSVC...

Answer 2

这是一个特殊的填充物，让异常处理程序/展开函数能够正确检测它是否是函数的序言/尾声/主体。

Answer 3

这是由于 x64 中的调用约定要求堆栈在任何调用指令之前对齐 16 个字节。这不是（据我所知）硬件要求，而是软件要求。这提供了一种方法来确保在进入函数时（即在调用指令之后），堆栈指针的值始终为 8 模 16。因此允许简单的数据对齐和从堆栈中对齐的位置存储/读取。