Polyspace 项目配置方法

最新推荐文章于 2025-03-31 18:19:35 发布

是华子哥啊

最新推荐文章于 2025-03-31 18:19:35 发布

阅读量1.3k

点赞数

文章标签： c++ linux c语言

本文链接：https://blog.csdn.net/weixin_41784289/article/details/128994073

版权

Polyspace支持C、C++和Ada代码分析，推荐使用自动配置方法，通过`polyspace-configure`获取编译选项。当自动配置不可行时，需手动配置编译器、处理器类型、预编译指令和头文件。验证内容包括编码规范、代码度量和缺陷检查，形式化分析则涉及应用级和模块级分析。配置过程兼顾灵活性和项目需求。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

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

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

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

自动配置方法可以参考下面的视频

从CMAKE项目自动生成静态分析Polyspace项目
400 播放 · 0 赞同视频
点击可播放视频

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

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

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

所选用的C语言标准：C90/C99
所用编译器类型：Keil/Tasking/Diab/IAR…
（编译器通常定义了标准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
如果在windows64平台下验证，需要告诉Polyspace您的分析平台: -D _WIN64

或者在UI界面定义

宏定义
#2.3 头文件
项目中除了项目本身的头文件外，编译器、硬件驱动的头文件也是项目的核心部分。在编译工具链中，这些已经都组织好了，也需要告诉Polyspace。添加头文件所在目录可以多，但是不能少。如果包含了多个同名的文件，主要找到正确的。尽量利用项目编译器的信息找到正确的配置项。

#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 Source Code Metrics
ww2.mathworks.cn/help/releases/R2022b/bugfinder/ug/his-metrics.html
设置直接勾选即可。Polyspace支持常见的代码信息度量

Code Metrics - MATLAB & Simulink - MathWorks China
ww2.mathworks.cn/help/releases/R2022b/bugfinder/metrics-reference.html?lang=en
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会被其他函数调用，需要更为鲁棒地分析其安全性。

— 总结 —
Polyspace的配置是一个既简单又灵活的过程，通过对编译器行为的模拟和分析模型的选择，我们可以得到更为有意义和更符合需要的结果。
而对于验证内容，则更多的看项目的需求。