c - GCC 优化导致奇怪的问题 - 我该如何调试？

Question

我在 C 程序中遇到 GCC 优化问题。它是 x86_64 代码(C 和内联汇编，虽然 .o 文件中没有 asm 很麻烦)，在 OS X 10.6 上运行。

这是使用 -O0 与 -O2 运行时的外观:

$ gcc -m64 -std=gnu99 -o bin/ctr keyschedule.c aes.c ctr.c debug.c misc.c -O0 -Wall
$ bin/ctr -e testing/plaintext -o testing/cipher
encrypt_file called with inpath: testing/plaintext
encrypt_file called with outpath: testing/cipher
file_size called with argument 0x7fff5fbff84b
nonce = 6e32b6797e849081
(... no more output, but it works as it should)

$ gcc -m64 -std=gnu99 -o bin/ctr keyschedule.c aes.c ctr.c debug.c misc.c -O2 -Wall
$ bin/ctr -e testing/plaintext -o testing/cipher
encrypt_file called with inpath: testing/plaintext
encrypt_file called with outpath: testing/cipher
file_size called with argument 0x7fff5f000000
Segmentation fault

...随着 OS X 崩溃报告器的弹出:

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fff5f000000
Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libSystem.B.dylib               0x00007fff88d3bad8 perror + 52
1   ctr                             0x0000000100001339 file_size + 73 (ctr.c:32)
2   ctr                             0x00000001000017be encrypt_file + 158 (ctr.c:72)
3   ctr                             0x0000000100001bd1 main + 289 (ctr.c:242)
4   ctr                             0x0000000100000bd4 start + 52

...这是所需的大部分代码(假设参数解析器相当临时):

int main(int argc, char *argv[]) {
...
    if (strcmp(argv[1], "-e") == 0)
        encrypt_file(argv[2], argv[4], key); // It crashes with static paths as well
...
}

void encrypt_file(const char *inpath, const char *outpath, const unsigned char *key) {
    printf("encrypt_file called with inpath: %s\n", inpath);
    printf("encrypt_file called with outpath: %s\n", outpath);

    // Create a pointer to the correct function to use for this CPU
    void (*aes_encrypt)(const unsigned char *, unsigned char *, const unsigned char *);
    if (test_aesni_support()) {
        aes_encrypt = aes_encrypt_aesni;
    }
    else {
        aes_encrypt = aes_encrypt_c;
    }

    unsigned char expanded_keys[176] = {0};
    aes_expand_key(key, expanded_keys);

    off_t size = file_size(inpath);
    if (size <= 0) {
        fprintf(stderr, "Cannot encrypt a file of size zero!\n");
        exit(1);
    }
    ....
}

off_t file_size(const char *path) {
    printf("file_size called with argument %p\n", path);
    struct stat st;
    if (stat(path, &st) != 0) {
        perror(path);
        exit(1);
    }

    return (st.st_size);
}

我怀疑我的代码中有什么东西(而不是假设错误在 GCC 中)，但我找不到任何东西。

如果上面的代码看起来没问题(我真的无法想象问题出在任何其他代码中，因为它与崩溃完全无关)，我应该怎么做才能找到它？

GDB:

#0  0x00007fff88d3bad8 in perror ()
(gdb) bt
#0  0x00007fff88d3bad8 in perror ()
#1  0x0000000100001339 in file_size (path=0x7fff5f000000 "") at ctr.c:31
#2  0x00000001000017be in encrypt_file (inpath=0x7fff5f000000 "", outpath=0x7fff5fbff860 "testing/cipher", key=0x7fff5fbff6b0 "-~??9?9>?W\n\021\001?N\026") at ctr.c:72
#3  0x0000000100001bd1 in main (argc=<value temporarily unavailable, due to optimizations>, argv=0x7fff5fbff718) at ctr.c:242
(gdb) frame 2
#2  0x00000001000017be in encrypt_file (inpath=0x7fff5f000000 "", outpath=0x7fff5fbff860 "testing/cipher", key=0x7fff5fbff6b0 "-~??9?9>?W\n\021\001?N\026") at ctr.c:72
72      off_t size = file_size(inpath);
(gdb) l
67      }
68  
69      unsigned char expanded_keys[176] = {0};
70      aes_expand_key(key, expanded_keys);
71  
72      off_t size = file_size(inpath);
73      if (size <= 0) {
74          fprintf(stderr, "Cannot encrypt a file of size zero!\n");
75          exit(1);
76      }

瓦尔格林德:

$ valgrind bin/ctr -e testing/plaintext -o testing/cipher
==1165== Memcheck, a memory error detector
==1165== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1165== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info
==1165== Command: bin/ctr -e testing/plaintext -o testing/cipher
==1165== 
encrypt_file called with inpath: testing/plaintext
encrypt_file called with outpath: testing/cipher
file_size called with argument 0x7fff5f000000
==1165== Syscall param stat64(path) points to unaddressable byte(s)
==1165==    at 0x2BB52: stat$INODE64 (in /usr/lib/libSystem.B.dylib)
==1165==    by 0x10000179D: encrypt_file (ctr.c:73) // this is the call to file_size() in encrypt_file()
==1165==    by 0x100001BB0: main (ctr.c:243)
==1165==  Address 0x7fff5f000000 is not stack'd, malloc'd or (recently) free'd
==1165== 
file_size: Bad address
==1165== 
==1165== HEAP SUMMARY:
==1165==     in use at exit: 4,184 bytes in 2 blocks
==1165==   total heap usage: 2 allocs, 0 frees, 4,184 bytes allocated
==1165== 
==1165== LEAK SUMMARY:
==1165==    definitely lost: 0 bytes in 0 blocks
==1165==    indirectly lost: 0 bytes in 0 blocks
==1165==      possibly lost: 0 bytes in 0 blocks
==1165==    still reachable: 4,096 bytes in 1 blocks
==1165==         suppressed: 88 bytes in 1 blocks
==1165== Rerun with --leak-check=full to see details of leaked memory
==1165== 
==1165== For counts of detected and suppressed errors, rerun with: -v
==1165== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

编辑:将 encrypt_file() 替换为未删节版本(直到它崩溃)，添加 GDB 信息并将 OS X 崩溃报告器输出替换为运行 -g 二进制文件的输出。

编辑 2:添加了 valgrind 输出。

Answer 1

看起来您的变量 inpath 正在(部分)被覆盖；我怀疑如果您删除对 aes_expand_key 的调用，它将顺利解决问题。

在没有看到 aes_expand_key 的情况下，我猜测它有一些内联汇编并且您没有正确保留至少一个根据目标平台的 ABI 应该保留的寄存器.在 -O0 的情况下，inpath 可能保留在堆栈中，因此不受影响，而在 -O2 的情况下，它可能保存在一个寄存器中，该寄存器的低 32 位被 aes_expand_key。