记录一次工具链升级引起段错误的调查报告

       由于导入软件架构的需求，需要对当前代码的编译环境进行升级，具体由gcc4.5.3升级到gcc11.3.1。原来环境是a40i ARM32环境,后续还会升级到ARM64的其他平台，代码主要由C语言构成，少量C++语言。

       我负责的一个业务模块主要是接收上位机通过socket发来的buf，完了将buf强转为对应结构体后赋值到这个数据该到的地方，完了根据上位机标志位，再保存到文件。我在通过上位机整体过功能的时候，发现上位机切换到特定页面，arm控制器程序会崩。第一反应，这是上位机不匹配么？什么鬼？那代码没几行啊，我也没改过。后来稍微空闲，和项目经理反馈了下，结果把这个任务安排给了我~解决不了问题，就把问题指给提出问题的人~

       后来通过printf与gdb，定位到了具体语句，再进一步print，发现两条语句单独打印都是ok的，但是两个组合就噶了。具体是将上位机buf强转为double数组，将数组赋值到全局变量。将情况丢给AI，基本是double数据的8字节对齐问题。将接收buf设置为8字节对齐，确实可以解决问题；AI也提供了其他可以尝试的方法，如设置编译选项，但是实际测试之后无法通过编译选项彻底解决。这里面其他团队也在升级编译链，也遇到了SIGBUS问题，加了两个编译选项，完了结论是部分解决但是没有完全解决……压力传递到了我这里……但是想通过一个小demo复现，又无法复现，所以直接下结论是有瑕疵的。AI还指出内核关于字节对齐问题的一个信息，/proc/cpu/alignment， 如果是2，则内核会进行修复。恰好系统这个参数就是2，这反而又增加了新的疑问。没啥好办法，顺着这个思路继续AI吧，最后表明2是系统回去试着修复，但是遇到了类似换页的地方是无法修复的，只能发出SIGBUS信号~

       不知道大家有没有疑问——为什么原来4.5.3编译器没有问题？通过查看汇编指令，发现老编译器没生成LDRD等字节敏感指令，新编译器却生成了不老少。新编译器为何会这样？减少机器周期，老编译器生成的指令，要对double分两次读取，新的一次就可以。另外测试出新编译器对数据库三角函数的执行效率提升30%多……

       最后是将整个流程同步给其他部门的同事，还需要输出一个编码规范……

       以前我是写Linux x86的，没遇到过这些情况，通过对问题求知的兴趣，最后定位到了问题，还有点儿小高兴。有两个小新得，①你要知道，铁铁，在绝大多数情况下，在你负责的细分领域，无人能出你其右。②从网络或是其他同事直接拿来的结论，需要再次甄别，他们结论也没错，但是某些特定条件下是不对的，但真正的问题的往往是弄清楚那些条件。

       问题不大也不小，给了5天时间。从同事那了解到，其他项目也遇到过，解决方式是改代码。但是并没有给出问题具体原因。

    欢迎关注：