EEPW论坛

背景

        客户拿我们做的机器对接外部供应商的算法，在对接算法过程中，外部供应商反馈我们的机器读到的ＩＭＵ数据中的时间戳有时会变成负数。

分析过程

        从负责此ＩＭＵ模块驱动模块的同事处了解到，这个时间并不是ＩＭＵ的时钟，而是使用的平台自带的时钟，暂不确定是哪出了问题。随机让同事加调试信息，安排煲机，经过漫长的煲机，发现确实会出现负数的情况。

        此时让同事用％ｌｌｘ的方式继续抓，从抓到的ｌｏｇ中看，发现在数据增加到０ｘ７ＦＦＦＦＦＦＦ后，只要数据再增加，后面的数据就会变成负数，但是呢，底层上报额数据是ｕｉｎｔ６４＿ｔ格式的，有点无厘头。

        由于同事加的ｌｏｇ不全，并没有体现是哪一层出的问题，遂让同事加全ｌｏｇ（主要是加各层的接收和向下一层上报处的ｌｏｇ）煲机。煲机后发现在获取时间戳时就已经出异常了。

       此时同事针对性的查看代码，发现代码并无异常，代码的伪代码为：

ａ．ｃ

ｕｉｎｔ６４＿ｔ　ｇｅｔ＿ｔｉｍｅ（ｖｏｉｄ）
｛
　　　　ｒｅｔｕｒｎ　ｘｘｘｘ；　／／　此处为芯片寄存器值
｝

ｂ．ｃ

ｕｉｎｔ６４＿ｔ　ｇｅｔ＿ｉｎｆｏ（ｓｔｒｕｃｔ　ｓｅｎｓｏｒ＿ｄａｔａ　＊ｄａｔ）
｛
　　　　ｄａｔ－＞ｘｘｘｘ　＝　ｘｘｘｘ；
　　　　
　　　　．．．．
　　　　ｄａｔ－＞ｔｉｍｅ　＝　ｇｅｔ＿ｔｉｍｅ（））；　／／　此处的ｔｉｍｅ也为ｕｉｎｔ６４＿ｔ的结构
｝

        从代码上来看，这个逻辑没毛病，从一个返回值为ｕｉｎｔ６４＿ｔ的函数中读到数据直接赋值给ｕｉｎｇ６４＿ｔ的变量，没有任何问题。

        但是考虑到此时发生了翻转，遂怀疑是不是寄存器本身给的信息错误，此时让同事将寄存器值改为变量值，每次读取时，变量都增加，查看是否异常，此时发现异常仍然存在，可以排除芯片本身设计问题。

        由于数据发生突变，此时怀疑是不是参数值传递时出现异常，因此让同事确认包含ｇｅｔ＿ｔｉｍｅ函数的头文件是否被ｂ，ｃ申明，此时一查，还真发现了问题，头文件并未被引用，遂让同事加上头文件后再次测试。经过测试，问题消失。

后续处理

        １．　让同事排查所有用到此函数的ｃ文件是否都有引用该头文件，确认完毕后出软件提交测试。测试通过后将修改项合并至代码主干。

        ２．　顺便让同事修改好上层接口，将上层读取数据结构体中的时间信息的格式与底层统一，确保不会出现数据交互时的信息突变。

背后原理

        在头文件未包裹的情况下，编译器会根据设定的规则去确认是否按报错处理，刚好我们拿到的供应商代码使用的是相对宽松的规则，此时编译时仅仅会报函数不存在，默认使用　ｉｎｔ　ｇｅｔ＿ｔｉｍｅ（ｖｏｉｄ）的虚拟接口编译成中间文件，而在链接时，由于函数ｕｉｎｔ６４＿ｔ　ｇｅｔ＿ｔｉｍｅ（ｖｏｉｄ）在另一个中间文件中存在，因此链接是也没报错。

        恰恰就是这种宽松的逻辑带来了问题，虽然函数返回值是ｕｉｎｔ６４＿ｔ格式的，但当ｂ．ｃ那边调用时，会将ｕｉｎｔ６４＿ｔ格式的数据转成ｉｎｔ格式给到ｄａｔ－＞ｔｉｍｅ，此时由于ｕｉｎｔ６４＿ｔ　到ｉｎｔ时，不是强制类型转换，而是仅仅类似于共享内存的方式（两边各自按照各自的格式去读写，读操作并不改变存储的值），也就造成了０ｘ８００００００在ｉｎｔ格式时对应的也是０ｘ８０００００００。

        之后又执行了一遍赋值操作，此时０ｘ８０００００００由于高位为１，到ｕｉｎｔ６４＿ｔ时，高位都会被补１。但此时还是不会有异常，因为格式是ｕｉｎｔ６４＿ｔ。偏偏我们拿到的代码又有另一个坑，内核给的ｔｉｍｅ是ｕｉｎｔ６４＿ｔ，ｆｒａｍｅｗｏｒｋ读数据时用的是ｉｎｔ６４＿ｔ，而数据交互过程又是采用共享内存的方式实现的，这就导致了上层拿到的数据因为最高位为１直接变成了负数了。