为什么同样的C代码在arm64-v8a可以跑，在armeabi-v7a会奔溃？

背景

使用NDK开发项目的一个安全库的时候，踩了一个坑。在这里做一个记录和总结，避免以后重复踩坑。
需求：开发安全库，用作密钥加密解密，体系位非对称密钥体系。
经历：使用的是合作公司提供的C源码，通过JNI接入C代码，提供给Java层调用。

过程

第一个坑

运行的时候Android stduio显示列链接错误，怀疑是CMake的问题。新建一个test.c和test.h可以正常运行。发现是C源码里面没有加上：

#ifdef __cplusplus
extern "C"
{
#endif
//c代码声明
#ifdef __cplusplus
};
#endif

导致C++链接时候和C的符号对不上，链接失败，坑的地方在于编译器没有提示这个问题。只能这样试出来。

第二个坑

前面几个接口可以正常运行，中间某个接口不能打印，程序不崩溃，只是不能打印。
同样的代码在Linux设备可以正常运行。
debug进去C源码里面进行代码review和数据观察分析，发现里面定义了long 、long long之类的变量。每次在某些循环操作里面断开debug。没能找出原因。
在代码里面加上数据打印，在怀疑的代码段加上大量的打印日志，观察数据是否越界。数据太多，也发现也没有越界导致crash。
调试和思路了半天，没有思路了。那另外一台机器来跑一下，bingo！
居然可以正常打印结果值了。

首先第一件想到的是，可能是cpu架构不同导致的。
第一台机器是arm64-v8a，第二台测试正常的cpu是armeabi-v7a。
好吧，他们的区别是一台是64位，一台是32位。
怀疑就是不同位数cpu里面数据长度不同导致的。

arm64-v8a 和 armeabi-v7a的区别

在Android开发中，arm64-v8a 和 armeabi-v7a 是两种不同的CPU架构。arm64-v8a 适用于64位ARM处理器，而 armeabi-v7a 适用于32位ARM处理器。

先来跑一个实例看看。

实例

void print64And32(){
    //写一个代码32位机器上运行时，输出sizeof（指针）的结果是多少，64位机器上运行时，输出sizeof（指针）的结果是多少？
    LOGD("sizeof(int) = %d\n", sizeof(int));
    LOGD("sizeof(long) = %d\n", sizeof(long));
    LOGD("sizeof(long long) = %d\n", sizeof(long long));
    LOGD("sizeof(char) = %d\n", sizeof(char));
    LOGD("sizeof(float) = %d\n", sizeof(float));
    LOGD("sizeof(double) = %d\n", sizeof(double));
    LOGD("sizeof(void *) = %d\n", sizeof(void *));
    LOGD("sizeof(char *) = %d\n", sizeof(char *));
    LOGD("sizeof(int *) = %d\n", sizeof(int *));
    LOGD("sizeof(long *) = %d\n", sizeof(long *));
    LOGD("sizeof(long long *) = %d\n", sizeof(long long *));
    LOGD("sizeof(float *) = %d\n", sizeof(float *));
    LOGD("sizeof(double *) = %d\n", sizeof(double *));

}

64位，Android设备CPU:arm64-v8a

sizeof(int) = 4
sizeof(long) = 8
sizeof(long long) = 8
sizeof(char) = 1
sizeof(float) = 4
sizeof(double) = 8
sizeof(void *) = 8
sizeof(char *) = 8
sizeof(int *) = 8
sizeof(long *) = 8
sizeof(long long *) = 8
sizeof(float *) = 8
sizeof(double *) = 8

32位，Android设备CPU:armeabi-v7a

sizeof(int) = 4
sizeof(long) = 4
sizeof(long long) = 8
sizeof(char) = 1
sizeof(float) = 4
sizeof(double) = 8
sizeof(void *) = 4
sizeof(char *) = 4
sizeof(int *) = 4
sizeof(long *) = 4
sizeof(long long *) = 4
sizeof(float *) = 4
sizeof(double *) = 4

基本数据类型在32位和64位的区别

从上述实测可以知道，在32位机器上，基本数据类型的大小如下：

• int：4字节
• long：4字节
• long long：8字节
• char：1字节
• float：4字节
• double：8字节

在64位机器上，基本数据类型的大小如下：

• int：4字节
• long：8字节
• long long：8字节
• char：1字节
• float：4字节
• double：8字节

需要注意的是，指针的大小在32位和64位机器上都是相同的，都是8字节。

指针长度在32位和64位的区别

32位机器上运行时，输出sizeof（指针）的结果是4。
64位机器上运行时，输出sizeof（指针）的结果是8。

其他可能性

1. 架构相关的问题： 你的应用程序可能包含了特定于 arm64-v8a 架构的代码，而这段代码在 armeabi-v7a 上无法正确运行。确保你的应用程序中没有架构相关的问题，并且所有的本地代码都是通用的。

2. 依赖库问题： 如果你的应用程序使用了本地库（例如C/C++库），这些库可能是特定于 arm64-v8a 的。确保你的应用程序包含适用于 armeabi-v7a 的版本的这些库。

3. 指令集兼容性： arm64-v8a 使用ARMv8-A指令集，而 armeabi-v7a 使用ARMv7-A指令集。确保你的应用程序中的本地代码对目标指令集是兼容的。

4. ABI Filters： 在你的 build.gradle 文件中，可能设置了 ABI Filters，导致只有 arm64-v8a 被打包到 APK 中。检查你的构建配置，确保包含了 armeabi-v7a 的支持。

chatgpt回答参考

当你的 C 代码在 32 位处理器上能够正常运行，但在 64 位处理器上出现问题时，可能有一些常见的原因：

1. 指针大小和类型问题： 64 位处理器上的指针大小为 8 字节，而在 32 位处理器上为 4 字节。如果你的代码中存在对指针大小的假设或者类型转换问题，可能导致在 64 位系统上出现问题。请确保你的代码对指针操作和类型大小有正确的处理。

2. 整数溢出： 如果你的代码依赖于特定的整数大小，可能会在 64 位系统上溢出。在 64 位系统上，int 类型仍然是 32 位，但 long 类型变为 64 位。确保你的代码中没有整数溢出的问题。

3. 对齐问题： 在 64 位系统上，对齐要求可能更加严格。如果你的代码依赖于特定的数据结构对齐方式，确保你的结构体或变量的对齐方式是正确的。

4. 未初始化变量： 64 位系统上的内存布局可能与 32 位系统不同。确保你的代码中所有的变量都被正确初始化，以防止使用未初始化的内存。

5. 依赖的库或第三方代码： 如果你的代码依赖于特定的库或第三方代码，确保这些库在 64 位系统上是兼容的。有时，问题可能并不是在你的代码中，而是在你依赖的库中。

6. 汇编语言代码： 如果你的代码包含了汇编语言部分，确保这些汇编语言代码是对 64 位系统的正确支持。

总体而言，要确保 C 代码能够在 64 位处理器上正确运行，需要注意 32 位和 64 位系统之间的差异，并确保代码中没有与平台相关的假设。最好的做法是使用编译器提供的宏来处理不同平台的区别，以确保代码的可移植性。