对齐异常alignment

对齐异常alignment

昨天终于解决了和ticon相关的alignment exception。

现象很明显，就是当dkm加了ticon相关的库以后，因为ticon本身代码编译出来是支持spe协处理器指令和矢量运算指令的，因此，最终的dkm二进制文件是有spe协处理器指令的，而那个指令读取数据必须是16字节对齐。

这个问题，辉姐曾经也遇见过，她的解决办法是：使用编译参数，让其不生成spe协处理器指令，没有了这个指令，当然读取数据是4字节对齐就可以啦噻。。也就是说间接跳过了这个问题。

然而，我们不能这么改，因为我们得不到ticon的源码，甚至编译参数都得不到，也就是说不能不让其生成这个spe协处理器指令。那么必须解决对齐异常！

通过异常信息，我们可以看到要访问的数据所在地址是：0x01508a7c。它是4字节对齐的，因此报错。

那么怎么才能让这个数据16字节对齐呢？

要回答这个问题，首先得知道这个数据可能放在那些地方。我认为可能的地方有：数据段，bss段，栈，堆。

全局变量，静态变量在data和bss中，因此，我在bss和data段的链接脚本里面都见了. = ALIGN(16);

局部变量在栈上面，因此我通过taskShow ID 2，查看了栈基址。也通过反汇编看出来了每个栈开始时都是减去16的倍数。

那么有没有可能是堆呢？我们查看了数据访问异常地址，然后通过taskShow ID 2，果然，在堆里！

既然找到了问题所在，解决就是关键。询问辉姐，得知堆的内存分配一般都和malloc相关，因此，当os正常运行后，我们在shell里，查看memDefaultAlignment的值，果然是4字节对齐！因此，在shell里，输入memDefaultAlignment=16，更改了字节对齐，然后测试，使用malloc 3来分配三个字节的空间，结果发现返回的地址是16字节对齐的了。再运行包含ticon的dkm项目，运行成功了！看见了小耗子吃奶酪的图形界面，问题解决！！！

等等，别急着高兴，这里也引出了一个更重要的问题，对一个问题的解决，不能知其然而不知其所以然，从根本入手，才是堂皇正道。因此，内存对齐的原理到底是什么？

询问笑哥以及查阅资料，我认识到：只要和内存相关和地址相关，那就肯定有内存对齐的问题。主要分两方面原因：

1. 平台原因：不是所有的硬件平台都能访问任意地址上的任意数据的；某些硬件平台只能在某些地址处取得某些特定类型的数据，否则抛出硬件异常。

2. 性能原因：经过内存对齐后，CPU的内存访问速度会大大提升。

在CPU眼中，内存不是按字节字节的分的，而是按块分的。块大小可以是2/4/8/16字节，因此CPU读取内存也是一块一块读的。块大小，称为memory granularity，即内存读取粒度。

对于对齐，我认为可以从两个方面考虑，一是对齐的基址，二是偏移。此次问题就是基址没有16字节对齐。

对于对齐基址，我想可以有以下几方面：任务栈基址，分配堆空间的malloc时使用的对齐基址，以及各种代码段，数据段的开始基址。

对于偏移，我做了以下实验：

image.png

结果发现：

image.png

也就是说两个结构体，仅仅里面包含的数据类型位置变了，sizeof出来的大小不一样！

这就是内存对齐的影响，这也是编译器干的活，编译器为每一个数据单元安排在合适的位置上。

内存对齐规则：

1. 对于结构的各个成员，第一个成员位于偏移为0的位置，以后每个成员的偏移量必须是min(#pragma pack(n)指定的数，这个数据成员自身长度)的倍数；

2. 在数据成员完成各自对齐之后，结构(或联合)本身也是要进行对齐，对齐将按照#pragma pack(n)指定的数值和结构最大数据成员大小中，比较小的那个进行。

pragma pack(n)表示设置为n字节对齐。

pragma pack()，则是取消自定义对齐方式。

这是一个预处理指令，且只对当前文件，且该预处理指令之后的数据生效。这是全局对其设置。

而单变量设置：

attribute((aligned(n))),让所作用的结构成员对齐在n字节自然边界上。如果结构中有成员的长度大于n，则按照最大成员的长度来对齐。

attribute((packed))，取消优化对齐。

image.png

结果如下：

image.png

但是看了我的举例，我又疑惑了，难道字节对齐就是用于结构体的吗？其实如果是普通的数据类型，那么我们就按照对齐规则2就行了。

那么，函数会按照字节对齐吗？

image.png

结果呢？

image.png

可见，对于函数，它是没有字节对齐的，挨着来就行了。而对齐，就是针对于数据，对齐异常，一般也就出现在数据访问了。