C(或任何)编译器的确定性性能

在最近的一个项目上工作时,我遇到了一位客户质量保证代表,他向我提出了一个我以前没有考虑过的问题:

您如何知道您使用的编译器生成的机器代码与C代码的功能完全匹配,并且编译器是完全确定的？

对于这个问题,我完全没有回复,因为我一直认为编译器是理所当然的.它接收代码并喷出机器代码.我怎样才能测试编译器实际上没有添加我没有要求的功能？甚至更危险地以与我期望的方式略有不同的方式实现代码？

我知道这对每个人来说并不是一个真正的问题,而且答案可能只是......"你已经超过了桶并处理它".但是,在嵌入式环境中工作时,您会隐式地信任您的编译器.我怎样才能向自己和QA证明我这样做是对的？

您可以在任何级别应用该参数:您信任第三方库吗？你相信操作系统吗？你相信处理器吗？

当然,这可能是一个有效关注的一个很好的例子,就是Ken Thompson如何将后门放入原始的"登录"程序......并修改了C编译器,这样即使你重新编译登录,你仍然有后门.有关详细信息,请参阅此帖子

关于加密算法也提出了类似的问题 - 我们怎么知道在NS中没有后门可以让NSA窥探？

在结束时,您必须决定是否信任您正在构建的基础架构,而不必担心它,否则您必须开始开发自己的硅芯片!

对于安全性至关重要的嵌入式应用程序认证机构要求满足编译器的"已证实使用"要求.通常需要满足某些要求(类似于"营业时间"),并通过详细的文档证明.但是,大多数人不能或不想满足这些要求,因为它可能非常困难,尤其是在您的第一个具有新目标/编译器的项目上.

另一种方法基本上是完全不信任编译器的输出.除了后面的功能测试之外,任何编译器甚至依赖于语言(C-90标准的附录G,任何人？)缺陷都需要通过严格的静态分析,单元和覆盖测试来涵盖.

像MISRA-C这样的标准可以帮助将编译器的输入限制为C语言的"安全"子集.另一种方法是将编译器的输入限制为语言的子集,并测试整个子集的输出是什么.如果我们的应用程序仅由子集中的组件构建,则假定已知编译器的输出将是什么.通常是"编译器的资格".

所有这一切的目标是能够回答质量保证代表的问题:"我们不仅仅依赖于编译器的确定性,而是我们证明它的方式......".

你知道通过测试.测试时,您正在测试您的代码和编译器.

你会发现你或编译器编写器出错的几率远小于你用某种汇编语言编写有问题的程序时出错的几率.

有编译器验证服.
我记得的是"常年".

当我在嵌入式SOC处理器的C编译器上工作时,我们不得不针对这个以及另外两个验证套件验证编译器(我忘记了它的名称).验证编译器符合这些测试诉讼的一定程度是合同的一部分.