Polyspace 项目配置方法

是华子哥啊

已于 2023-04-23 15:34:11 修改

阅读量502

点赞数

文章标签： c语言

于 2023-04-23 15:26:38 首次发布

原文链接：https://zhuanlan.zhihu.com/p/602489534

版权

Polyspace 可以分析 C、C++ 以及 Ada 代码。本文以最为常见的 C 代码分析为例说明 Polyspace 配置一个工程的过程和注意事项。

Polyspace 项目配置是有自动方法和手动方法。推荐使用自动的方法，当自动方法报错时，使用手动方法。

1. 跟踪编译系统自动配置

自动配置方法是跟踪编译指令，自动获取相关选项的方法，相关的选项包括源文件列表、头文件目录、库文件目录、预编译指令等等。

自动配置方法有 2 个要求。

项目能在本地编译，并进行全新的编译

polyspace 支持您的编译器。polyspace 支持市面上常见的编译器，如 GNU C/C++,Keil, VC++, ARM® v5v6, Clang, Green Hills 等等。请联系我们进一步确定您的编译器是否支持。

如果满足上述要求，就可以使用 polyspace-configure 自动配置了。

1.1 使用 polyspace-configure 自动配置

polyspace-configure 是 polyspace 的一个函数，提供命令行和交互式方式调用。

基本的命令是

polyspace-configure -output-options-file opt-file make -B
其中 make -B 是 rebuild 指令。

图片
执行polyspace-configure以生成选项文件

图片
自动配置可以从编译指令获取选项，也可以将编译指令编译为 json 编译数据库后获取；

如果您在使用上述方法时遇到问题，请联系 MathWorks 技术人员。

1.2 自动配置后的手动调整

自动配置后很多情况下都可以直接使用了。但是也有个别的情况下，需要手动添加相关的选项方可。这种情况一般是编译系统复杂，多个命令系统来回调用造成的；如果从 JSON 文件自动配置，也会有这个问题。

手动调整因项目而已，有问题可以联系 MathWorks 公司的技术人员。

2. 手动配置方法

如果您的编译器不支持自动配置，比如古老的 C51，那只能尝试使用手动的方法。

配置项主要包括编译器相关、项目文件相关等。

2.1 配置编译器和处理器类型

C 语言由于其灵活性，在不同的编译器中有不同的约束和扩展，会影响最终生成的目标码的行为。Polyspace 分析 C 代码时首先要最大程度和目标编译器的行为保持一致，这样才能保持代码分析的意义。因此在开始创建 Polyspace 工程时，我们需要配置编译器和处理器类型：

图片
所选用的 C 语言标准：C90/C99

所用编译器类型：Generic/Grun/Keil/Tasking/Diab/IAR…

（这里选择的是，以该编译器配置为基线配置。如果不确定，请选择 Generic。编译器通常定义了标准 C 语言之外的扩展，如关键字 sfr、sbit 等。选定编译器类型相当于告知了 Polyspace 在遇到此类非标扩展时如何解释其行为。）

目标处理器类型：定义不同数据类型的大小和字节顺序类型，如 mpc5xx 系列处理器定义如下：

图片
定义目标机

（某些运行时错误检查与此有关，如同一变量在 int 定义为 16 位时会发生溢出，而在 int 定义为 32 位时不会发生溢出。）

其他编译器行为设定：如负除取整方向、有符号数右移逻辑、枚举类型定义方式等。

2.2 预编译指令

项目因为防御编程、不同阶段的设计需要和效率需求等，会有很多预编译指令，一些指令会影响程序的逻辑，因此需要告诉 Polyspace。

举个简单例子，如果代码中有这段命令

#ifdef _WIN32 /* Windows 32 or Windows 64 /
PT_MAKE_STR( _WIN32 ),
#endif
#ifdef _WIN64 / Windows 64 /
PT_MAKE_STR( _WIN64 ),
#endif
#ifdef MINGW32 / Windows32 by mingw compiler */
PT_MAKE_STR( MINGW32 ),
#endif
其中 make -B 是 rebuild 指令。

如果在 windows64 平台下，需要告诉 Polyspace 您的分析平台: -D _WIN64

或者在 UI 界面定义

图片
3. 选择验证的内容

验证的内容来自项目的需求，可能是行业常用的规范，安全标准、公司的严格要求等等。

在静态分析方面，主要涉及编码规范、命名规范、缺陷的选择等。我们从这些角度来说。

3.1 编码规范和代码度量

编码规范来自项目的安全等级，衍生处要满足哪些规范。常见的有 MISRA C 2004/2012, MISRA C++2008, AUTOSAR C++14 JSF C++，信息安全方面有 CWE, CVE, CERT C/C++、ISO17961 等等。

Polyspace 针对不同的规范提供类别的快速选择和某条规则的小颗粒度选择。以最常用的 MISRA C 2012 为例，可以选择强制、强制推荐等，也可以自定义

图片
图片
推荐在项目之初就确定检查的规则。如果没有定义，最严格的强制类规则开始，逐渐降低。

代码信息度量则更多的是统计代码的相关指标，比如圈复杂度。这也需要定义项目相关的指标。汽车行业常见的指标是 HIS，定义了常见的指标的阈值。

HIS 代码复杂度度量：https://ww2.mathworks.cn/help/bugfinder/ug/his-metrics.html
设置直接勾选即可。Polyspace 支持常见的代码信息度量

代码度量：https://ww2.mathworks.cn/help/bugfinder/metrics-reference.html

3.2 缺陷检查

和规则一样，缺陷也可以按照不同的集合，比如 default 和自己选择。选择时更多的来自于对质量的要求。缺陷的影响分高中低三类，在工程实践中，也是按照高危问题逐渐降低的方式选择。

图片
不管是规则还是缺陷，还可以全部勾选，在结果审查的时候，选择特定的类别予以评审修改。

3.3 形式化分析

形式化分析的选择相对复杂。总的原则是，从单元到集成，从模块到应用，从低精度到高精度。

Polyspace Code Prover 有两种基本的验证分析模式：应用级分析和模块级分析，可以分别对应于集成测试和单元测试。

所谓应用级分析指用户待分析的源代码中包含了 main 函数，选择应用级分析即分析进程从用户 main 函数入口，为了更好地模拟实际程序运行和调度情形，有时需要进行多任务（Multitasking）设置，有机会在以后再进一步介绍。

模块级分析通常待分析代码不包含 main 函数，Polyspace 会自动打桩生成 main 函数并建立待分析函数的调用关系进行分析，并可进一步根据需要细化配置。如对于以下被调函数 Function_sub 和主调函数 Function_top，可以设置为以下两种分析入口形式：

Function_sub(){ ……}; Function_top(){…… Function_sub(); ……};
自动生成的 main 函数中只调用 Function_top：在分析 Function_top 的进程中分析 Function_sub，即 Function_sub在 Function_top 的上下文中被分析。

自动生成的 main 函数中同时调用 Function_top 和 Function_sub：Function_sub 除了在 Function_top 的上下文中被分析，也会在直接在main函数上下文中被分析。对应的可能场景是 Function_sub 会被其他函数调用，需要更为鲁棒地分析其安全性。

图片