优化版代码中的 SIGSEGV答案

【问题标题】：SIGSEGV in optimized version of code优化版代码中的 SIGSEGV
【发布时间】：2012-01-08 08:16:45
【问题描述】：

我对 intel 指令集的了解有点生疏。你能告诉我为什么我的函数的优化版本可能会出现分段错误吗（如果你能告诉我为什么我在代码的 -O0 构建中没有得到它，那就加分吧。

是 GCC 4.1.2 编译的 C 代码。

这是崩溃时 GDB 的“disas”命令的结果：

   0x00000000004263e5 <+0>:     sub    $0x8,%rsp
   0x00000000004263e9 <+4>:     movsd  %xmm2,(%rsp)
   0x00000000004263ee <+9>:     divsd  %xmm1,%xmm0
   0x00000000004263f2 <+13>:    callq  0x60f098 <log@plt>
=> 0x00000000004263f7 <+18>:    andpd  0x169529(%rip),%xmm0        
   0x00000000004263ff <+26>:    movsd  (%rsp),%xmm1
   0x0000000000426404 <+31>:    ucomisd %xmm0,%xmm1
   0x0000000000426408 <+35>:    seta   %al
   0x000000000042640b <+38>:    movzbl %al,%eax
   0x000000000042640e <+41>:    add    $0x8,%rsp
   0x0000000000426412 <+45>:    retq

这是函数的原始来源：

char is_within_range(double a, double b, double range) {
  double ratio = a / b;
  double logRatio = fabs(log(ratio));
  return logRatio < range;
}

这里是代码的非优化版本供参考：

   0x00000000004263e5 <+0>: push   %rbp
   0x00000000004263e6 <+1>: mov    %rsp,%rbp
   0x00000000004263e9 <+4>: sub    $0x30,%rsp
   0x00000000004263ed <+8>: movsd  %xmm0,-0x18(%rbp)
   0x00000000004263f2 <+13>:    movsd  %xmm1,-0x20(%rbp)
   0x00000000004263f7 <+18>:    movsd  %xmm2,-0x28(%rbp)
   0x00000000004263fc <+23>:    movsd  -0x18(%rbp),%xmm0
   0x0000000000426401 <+28>:    divsd  -0x20(%rbp),%xmm0
   0x0000000000426406 <+33>:    movsd  %xmm0,-0x10(%rbp)
   0x000000000042640b <+38>:    mov    -0x10(%rbp),%rax
   0x000000000042640f <+42>:    mov    %rax,-0x30(%rbp)
   0x0000000000426413 <+46>:    movsd  -0x30(%rbp),%xmm0
   0x0000000000426418 <+51>:    callq  0x610608 <log@plt>
   0x000000000042641d <+56>:    movapd %xmm0,%xmm1
   0x0000000000426421 <+60>:    movsd  0x16b6b7(%rip),%xmm0
   0x0000000000426429 <+68>:    andpd  %xmm1,%xmm0
   0x000000000042642d <+72>:    movsd  %xmm0,-0x8(%rbp)
   0x0000000000426432 <+77>:    movsd  -0x8(%rbp),%xmm1
   0x0000000000426437 <+82>:    movsd  -0x28(%rbp),%xmm0
   0x000000000042643c <+87>:    ucomisd %xmm1,%xmm0
   0x0000000000426440 <+91>:    seta   %al
   0x0000000000426443 <+94>:    movzbl %al,%eax
   0x0000000000426446 <+97>:    leaveq 
   0x0000000000426447 <+98>:    retq

【问题讨论】：

您是否检查了与未优化代码（汇编输出）的差异？如果是的话，你也可以发布它吗？
我认为输入实际上并不重要......
那个版本的 GCC > 4.5 岁。这可能是旧版 GCC 的优化错误。
为什么该指令首先会导致段错误？我认为这与数百万种寻址模式有关，但也许有人可以参与进来？
你有#include <math.h>吗？

标签： c gcc assembly segmentation-fault

【解决方案1】：

=> 0x00000000004263f7 <+18>:    andpd  0x169529(%rip),%xmm0        
   0x00000000004263ff <+26>:    movsd  (%rsp),%xmm1

andpd 指令接受内存操作数时，需要对齐到 16 字节边界。

对于%rip-相对寻址，偏移量应用于以下指令的地址。所以，这里的内存操作数在0x4263ff + 0x169529 = 0x58f928，不是16字节对齐的。因此出现了段错误。

编译器直接为fabs()生成代码，使用带有适当位掩码的AND来清除符号位；位掩码常量值应该已放置在充分对齐的数据部分中的适当偏移处，但尚未放置。这可能是那个（旧）版本的 GCC 中的错误，或者可能是其他地方的链接器相关问题。

【讨论】：

对此的跟进是，您的答案是正确的，事实证明这是我们正在使用的非标准链接器中的链接器错误。感谢您的回答。

【解决方案2】：

我也在使用gcc (GCC) 4.1.2 20070115 (SUSE Linux)，这是生成的程序集：

Dump of assembler code for function is_within_range:
0x0000000000400580 <is_within_range+0>: divsd  %xmm1,%xmm0
0x0000000000400584 <is_within_range+4>: sub    $0x8,%rsp
0x0000000000400588 <is_within_range+8>: movsd  %xmm2,(%rsp)
0x000000000040058d <is_within_range+13>:        callq  0x400498 <log@plt>
0x0000000000400592 <is_within_range+18>:        andpd  358(%rip),%xmm0        # 0x400700
0x000000000040059a <is_within_range+26>:        xor    %eax,%eax
0x000000000040059c <is_within_range+28>:        movsd  (%rsp),%xmm1
0x00000000004005a1 <is_within_range+33>:        ucomisd %xmm0,%xmm1
0x00000000004005a5 <is_within_range+37>:        seta   %al
0x00000000004005a8 <is_within_range+40>:        add    $0x8,%rsp
0x00000000004005ac <is_within_range+44>:        retq

看起来几乎一样，但我没有崩溃。我认为您需要向我们提供您的编译器标志，以及您的处理器和 GLIBC 版本的详细信息，以及为您崩溃的 a、b 和 range 的值，因为问题几乎肯定是与log 通话。

【讨论】：

【解决方案3】：

调用log函数后好像崩溃了：

callq  0x60f098 <log@plt>

所以fabs 实现可能存在问题，使用-O0。

你试过了吗：

double logRatio = log(ratio);
logRatio = fabs(logRatio);

这可能会生成不同的程序集输出，并且您可能会获得有关崩溃的其他信息。

作为替代方案，您可以将 fabs 调用替换为以下内容：

double logRatio = log(ratio);
logRatio = (logRatio < 0) -logRatio : logRatio;

您可能对此有精度问题，但这不是重点...

【讨论】：