简单分析针对ARM平台的C语言程序的编译问题

  我们知道在C语言编译时,有那么几个常用的优化编译选项,分别是-O0,-O1,-O2,-O3以及-Os。之前一直觉得既然是优化选项,顶多是优化一下逻辑,提高一些效率或者减少一下程序大小而已。很少会觉得它们会影响程序的最终结果。直到最近在ARM平台上发现一个程序里的一个bug,才觉得这些优化选项有时候也没那么智能。或者说针对ARM平台,还没有那么智能。
      首先看这么一段程序,此程序是我将问题简单化的程序:

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

int main()
{
 char buffer[1024] = {0,1,2,3,4,5,6,7};
 int iTest = 0x12345678;
 int *p = (int *)(buffer + 7);
 memcpy(p, &iTest, sizeof(iTest));
 printf("%x\n", buffer[6]); 
 printf("%x\n", buffer[9]); 
 return 0;
}

乍看之下,觉得这个程序没啥问题。然后我们将此程序文件名称叫point.c。然后分别用交叉编译链进行如下编译:

 arm-xxx-linux-gcc point.c -o point0 -O0
 arm-xxx-linux-gcc point.c -o point1 -O1
 arm-xxx-linux-gcc point.c -o point2 -O2

    最终再分别执行三个程序,结果却有点出人意料:

 ./point0
 6
 34
 ./point1
 34
 0
 ./point2
 6
 0

    只有在-O0,也就是没有优化的情况下,结果才和假想的一致。但是同样的问题在x86平台上却没有问题。
    于是我通过用以下命令,分别来生成不同优化选项下的汇编代码,来确定在ARM平台上编译到底出了什么问题。

 arm-xxx-linux-gcc point.c -o point0.s -O0 -S
 arm-xxx-linux-gcc point.c -o point1.s -O1 -S
 arm-xxx-linux-gcc point.c -o point2.s -O2 -S

    然后对比三个汇编的代码,发现问题出在memcpy这句话上。
    在point0.s中,程序是老老实实的调用的memcpy,然后就将0x12345678老老实实按照字节一个个的放到了buffer+7的位置。
    而在point1.s中程序则是没有调用memcpy,而是用的语句:
    str        r3, [sp, #7]
    而此时r3中存储的就是0x12345678;而由于我采用的ARM平台是32位的,此语句执行时,地址线应该不会发生变化,所以最终的结果是buffer+4到buffer+7的数据被覆盖了,而不是buffer+7到buffer+10的数据被修改。
    而在point2.s中,貌似又针对流水线进行了优化,程序执行顺序会有所变化,在对buffer部分位置赋初值的顺序是在str  r3, [sp, #7]之后,所以buffer+6处的数据反而是正确的6。
    分析到这儿,也许有人会说写个简单的程序,都会因为编译的优化选项不同导致结果不同,那这memcpy是不是就不敢用了?
    其实一般只要有较好的编程习惯的话,都不会遇到此类问题,比如下面的程序:

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

int main()
{
 char buffer[1024] = {0,1,2,3,4,5,6,7};
 int iTest = 0x12345678;
 char *p = buffer + 7;
 memcpy(p, &iTest, sizeof(iTest));
 printf("%x\n", buffer[6]); 
 printf("%x\n", buffer[9]); 
 return 0;
}

    这段程序其实只是简单的改变了p的类型,就能保证在各种优化下,结果都一样。可见好的编程习惯是有多么的重要。

声明:本文内容来源于网络,版权归原作者所有,内容由互联网用户自发贡献自行上传,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任。如果您发现有涉嫌版权的内容,欢迎发送邮件至:notice#cainiaojc.com(发邮件时,请将#更换为@)进行举报,并提供相关证据,一经查实,本站将立刻删除涉嫌侵权内容。