简单分析针对ARM平台的C语言程序的编译问题
我们知道在C语言编译时，有那么几个常用的优化编译选项，分别是-O0,-O1,-O2,-O3以及-Os。之前一直觉得既然是优化选项，顶多是优化一下逻辑，提高一些效率或者减少一下程序大小而已。很少会觉得它们会影响程序的最终结果。直到最近在ARM平台上发现一个程序里的一个bug，才觉得这些优化选项有时候也没那么智能。或者说针对ARM平台，还没有那么智能。
首先看这么一段程序，此程序是我将问题简单化的程序：
#include<stdio.h>
#include<string.h>
intmain()
{
charbuffer[1024]={0,1,2,3,4,5,6,7};
intiTest=0x12345678;
int*p=(int*)(buffer+7);
memcpy(p,&iTest,sizeof(iTest));
printf("%x\n",buffer[6]);
printf("%x\n",buffer[9]);
return0;
}
乍看之下，觉得这个程序没啥问题。然后我们将此程序文件名称叫point.c。然后分别用交叉编译链进行如下编译：
arm-xxx-linux-gccpoint.c-opoint0-O0 arm-xxx-linux-gccpoint.c-opoint1-O1 arm-xxx-linux-gccpoint.c-opoint2-O2
最终再分别执行三个程序，结果却有点出人意料：
./point0 6 34 ./point1 34 0 ./point2 6 0
只有在-O0，也就是没有优化的情况下，结果才和假想的一致。但是同样的问题在x86平台上却没有问题。
于是我通过用以下命令，分别来生成不同优化选项下的汇编代码，来确定在ARM平台上编译到底出了什么问题。
arm-xxx-linux-gccpoint.c-opoint0.s-O0-S arm-xxx-linux-gccpoint.c-opoint1.s-O1-S arm-xxx-linux-gccpoint.c-opoint2.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>
intmain()
{
charbuffer[1024]={0,1,2,3,4,5,6,7};
intiTest=0x12345678;
char*p=buffer+7;
memcpy(p,&iTest,sizeof(iTest));
printf("%x\n",buffer[6]);
printf("%x\n",buffer[9]);
return0;
}
这段程序其实只是简单的改变了p的类型，就能保证在各种优化下，结果都一样。可见好的编程习惯是有多么的重要。