关于编译器错误的防护措施
近期收到一个关于TI 编译器错误防护的反馈，客户担心编译器存在故障导致出现编译错误影响系统安全性，需要我们给出解决办法，有一种方案就是在编译器编译时在程序的代码段或数据段中的某些位置写入安全码，然后再运行中检测的方式。但是没有具体的操作方案，不知道给位有没有什么好的建议。 本帖最后由 xf331785508 于 2017-4-18 16:02 编辑我能理解成固定位置的CHECKSUM定义，运行时再检测固定地址的CHECKSUM是否是写入的值？？？
#define FLASH_ROM_CHECKSUM_ADDR0x0800EEFFul
#pragma location = FLASH_ROM_CHECKSUM_ADDR
_root const static uint32_t scdwCheckSum= 0x12349876;
globalbool gyCheckSumParity( void )
{
uint32_t dwCheckSumRead;
dwCheckSumRead = *((uint32_t*)FLASH_ROM_CHECKSUM_ADDR);
return (( dwCheckSumRead != scdwCheckSum ) ? false : true);
}
xf331785508 发表于 2017-4-18 15:47
我能理解成固定位置的CHECKSUM定义，运行时再检测固定地址的CHECKSUM是否是写入的值？？？
但是什么时候写入呢？如果在程序运行起来后写入读出，是不是就跟编译器没关系了？谢谢 s15200380596 发表于 2017-4-18 16:02
但是什么时候写入呢？如果在程序运行起来后写入读出，是不是就跟编译器没关系了？谢谢 ...
这样定义好了后，编译，生成ROM映象文件（.bin or .hex）， 程序下载到ROM时即写入了，运行的时候去那个固定地址读就行。 xf331785508 发表于 2017-4-18 16:04
这样定义好了后，编译，生成ROM映象文件（.bin or .hex）， 程序下载到ROM时即写入了，运行的时候去那个 ...
“程序下载到ROM时即写入了” 意思是不是程序每次运行起来都会先写入安全码，然后再读安全码。 s15200380596 发表于 2017-4-18 16:18
“程序下载到ROM时即写入了” 意思是不是程序每次运行起来都会先写入安全码，然后再读安全码。 ...
呃，。。。 你难道对MCU烧录过程不太了解？？ 源码-->编译（用编译器）-->生成二进制文件-->特定ISP工具烧录进FLASH ROM-->上电运行 编译器故障？那只能编译器厂家修正吧？
写的程序还能纠正编译器故障？
本帖最后由 s15200380596 于 2017-4-18 16:46 编辑
xf331785508 发表于 2017-4-18 16:25
呃，。。。 你难道对MCU烧录过程不太了解？？ 源码-->编译（用编译器）-->生成二进制文件-->特定ISP工 ...
我的意思是，每次上电运行后应该都会执行一遍写安全码跟读安全码。但是我还有个疑问就是假如编译器出某种故障了，它是不是刚好影响写安全码跟读安全码呢？假如只影响其他地方，那对比安全码是不是也不能诊断出故障？ KongQuan 发表于 2017-4-18 16:39
编译器故障？那只能编译器厂家修正吧？
写的程序还能纠正编译器故障？
不是纠正，诊断出故障后做安全相关的处理，至少保证程序不继续执行下去。因为安全要求较高。 s15200380596 发表于 2017-4-18 16:45
不是纠正，诊断出故障后做安全相关的处理，至少保证程序不继续执行下去。因为安全要求较高。 ...
如何知道编译器产生错误？
你是不是指的是烧录的程序和原始程序不同？ KongQuan 发表于 2017-4-18 16:52
如何知道编译器产生错误？
你是不是指的是烧录的程序和原始程序不同？...
据我的测试，gcc在编译mips代码时有时会出现错误，从asm看能找到漏掉的代码段。现在我要开no delay slot和o2才能保证代码正常运行。lz莫非指编译器编译出错？这类优化错误不好说。 wye11083 发表于 2017-4-18 17:01
据我的测试，gcc在编译mips代码时有时会出现错误，从asm看能找到漏掉的代码段。现在我要开no delay slot ...
就是看不明白lz的问题。
我也知道，编译器可能会有错误产生，这个，编写的应用程序根本无法预防吧，只能在出现无法解释时，从反汇编看看是否编译器优化产生了问题 wye11083 发表于 2017-4-18 17:01
据我的测试，gcc在编译mips代码时有时会出现错误，从asm看能找到漏掉的代码段。现在我要开no delay slot ...
恩恩，编译器的编译错误。 编译器故障？编译出了错误的代码？这个可麻烦了，基本上需要茫茫多的测试用例来测试每一个编译语意编译出来的代码是符合该语意的，然后还有各种语意组合的用例测试。基本不要想搞。 flamma 发表于 2017-4-18 18:32
编译器故障？编译出了错误的代码？这个可麻烦了，基本上需要茫茫多的测试用例来测试每一个编译语意编译出来 ...
优化bug更多。一般除了非常简单的，以及对大小有严格限制，还是不要用os。x86因为很广泛，可以认为基本没有bug wye11083 发表于 2017-4-18 20:23
优化bug更多。一般除了非常简单的，以及对大小有严格限制，还是不要用os。x86因为很广泛，可以认为基本没 ...
假如不使用编译器优化功能，是不是编译器出错的几率就会很小？ 都担心到编译器上了，这个是不是需要按 功能安全型控制器 思路去设计了？IEC 61508不知道有么有这方面的描述。 s15200380596 发表于 2017-4-19 09:50
假如不使用编译器优化功能，是不是编译器出错的几率就会很小？
cpu硬件可能会出错（不合理的读写次序）。优化之后读写调度会好一些。 wye11083 发表于 2017-4-19 11:17
cpu硬件可能会出错（不合理的读写次序）。优化之后读写调度会好一些。
编译器优化错误跟编译器本身编译错误，感觉都有随机性吧，就是并不知道会在哪里出错，是不是不好做防护？ s15200380596 发表于 2017-4-20 09:01
编译器优化错误跟编译器本身编译错误，感觉都有随机性吧，就是并不知道会在哪里出错，是不是不好做防护？ ...
比如gcc能追踪十几级case，但是在有一次优化时就把我的一个case给优化没了。
这类问题防不胜防，只能去查asm。 wye11083 发表于 2017-4-20 09:06
比如gcc能追踪十几级case，但是在有一次优化时就把我的一个case给优化没了。
这类问题防不胜防，只能去查 ...
这还是靠单元测试之类的来保证吧，碰到问题绕过去，顶多反馈一下，
想个人或小团队解决compiler issue，
说句不好听的话，就是笑话 我觉得你们还没把问题理清，其实担心的是一致性问题，这个可以通过早期充分的测试来保证，运行时加那一段没用，运行时加的测试应该在测试阶段就进行，测试过了，运行时也不会有区别 xycfwrj 发表于 2017-4-20 11:16
这还是靠单元测试之类的来保证吧，碰到问题绕过去，顶多反馈一下，
想个人或小团队解决compiler issue，
...
单元测试没用。单个测试怎么都是好的。只有实际使用才会暴露出一些bug。 个人感觉TI的编译器是最不可靠的，会出现莫名奇妙的段错误 本帖最后由 xycfwrj 于 2017-4-20 12:48 编辑
wye11083 发表于 2017-4-20 12:06
单元测试没用。单个测试怎么都是好的。只有实际使用才会暴露出一些bug。 ...
这种问题和编译器没关系。
中兴华为几M的基站跑着，核心都是dsp，
没听说编译器错误造成问题的，
古怪一点的问题你说软失效都合理点，
当然更合理的解释就是代码有问题，比如内存溢出什么的，
就是corner case没测充分 xycfwrj 发表于 2017-4-20 12:44
这种问题和编译器没关系。
中兴华为几M的基站跑着，核心都是dsp，
没听说编译器错误造成问题的，
这类问题都不好测。你不知道什么时候case就少了一项。 wye11083 发表于 2017-4-20 13:58
这类问题都不好测。你不知道什么时候case就少了一项。
编译器可能有两种故障，一种是本身编译器编译就产生错误（几率小）导致程序大面积错误代码无法执行，另一种是由于编译优化导致的问题。第一种情况下程序大面积失效无法进行防护，第二种情况下可以不使能编译优化功能及进行模块、需求测试来避免优化异常，编译优化错误存在不确定性所以也无法做防护。可不可这样理解？
页:
[1]