在进行嵌入式工程的配置过程中，“TASKING编译选项应当如何设置、由其引起的报警数量增多应当如何排查”属于常见的问题。编译选项在TASKING中不仅是优化等级的开关，头文件搜索、宏定义、语言标准、报警等级、MISRA检查、链接脚本以及最终生成文件也都会受到其影响。当报警数量突然上升的时候，把它们全部屏蔽掉的做法是不可取的，首先需要判断的是配置被收紧了，还是代码中本来就隐藏着隐患。

　　一、TASKING编译选项设置的具体操作

　　在通常情况下，工程属性界面是设置TASKING编译选项的地方，直接对生成文件或者中间配置文件进行修改是不被建议的。因为这些文件的一部分会被IDE进行自动更新，在手动修改完成之后虽然看起来生效了，但是在后续刷新工程的时候，它们很有可能会被重新覆盖。

　　1、进入工程编译配置的路径

　　【Project】→【Properties】→【C/C++Build】→【Settings】是常见的操作路径。在进入到该界面之后，编译器、汇编器、链接器等工具的设置就会被看到。虽然不同芯片工具链的界面名称可能存在微小的差别，但是它们大体上都会被划分在Compiler、Assembler、Linker等栏目下面。

　　在此处，配置对象是需要被特别注意的。许多工程都同时存在Debug、Release或者自定义配置，在修改进行之前，作者必须看清当前被选中到底的是哪一个配置。如果只对Debug进行了修改，而Release没有被修改，在后续切换配置之后就会再次报错，这种情况在实际操作中经常发生。

　　2、对常用编译参数进行设定

　　在编译选项当中，Include路径、宏定义、优化等级、语言标准、报警等级以及目标芯片的相关参数，都是比较常需要做出调整的内容。

　　头文件能不能被找到，主要由Include路径决定；条件编译则会受到宏定义的影响，例如某些模块是否被启用、芯片型号是否匹配、调试功能是否被打开等；代码体积、运行效率和调试体验都会受到优化等级的影响；而编译器对可疑代码的提示强度，则是由报警等级决定的，错误、警告、提示等类别通常是TASKING诊断信息进行分类显示的依据，更为详细的诊断还可以去Problems视图里面进行查看。

　　3、链接相关的选项不应混合修改

　　在看到工程报错的时候，很多人往往只把目光盯着C Compiler，其实Linker配置才是某些问题所属的部分。比如库路径的不正确、启动文件的不匹配、LSL链接脚本的选错，这些可能都不是编译阶段产生的问题，而是链接阶段产生的问题。

　　如果AURIX、TriCore等平台被项目所采用，LSL文件就尤其需要被谨慎对待。存储区分配、段放置、中断向量位置和多核资源布局都会受到链接脚本的影响。除非芯片型号、内存布局、启动方式以及工程结构都被确认是一致的，否则其他项目的链接脚本不应该被随便套用。

　　二、TASKING编译选项导致报警增多怎么排查

　　报警数量的增多并不一定代表坏事。这有时是因为编译器的检查变得更严苛了，从而把以前没有被发现的问题提示了出来；也有可能是选项在迁移时出现了错误，从而把不适合当前工程的规则给打开了。

　　1、首先对报警开始变多的时间点进行确认

　　在排查的过程中，急着去改动代码是不对的，最近做过什么变更应该先被回看。比如TASKING版本是否被升级了、Debug和Release是否被切换了、别的工程配置是否被导入了、更高等级的报警是否被打开了、MISRA检查是否被启用了，或者是宏定义和include路径是否被修改了。

　　如果报警是在“导入工程配置”这一操作之后集中出现的，新旧工程的编译选项应该被优先对比。Diagnostics、Preprocessor、Optimization、Include Paths、Language、MISRA、Linker Script等位置需要被重点查看。很多报警并不是因为代码突然变差了，而是因为编译器现在看到了不同的代码分支。

　　2、对报警编号进行观察，而不是仅仅看报警的数量

　　在报警数量变多的时候，Problems视图里的红黄标记不能成为唯一的观看对象。具体的报警应该被点开，报警编号、文件位置以及触发原因都需要被观察。更详细的诊断信息是支持在TASKING的Problems视图中被查看的，指定诊断说明也可以通过--diag命令来查看。

　　3、对“真实代码问题”与“规则过严问题”进行区分

　　真实的代码问题是必须被修复的，比如数组越界的风险、指针类型的不匹配、未初始化的变量、函数声明和定义的不一致。为了界面的清爽而关闭这些报警是不行的。

　　规则过严的问题则需要结合项目的阶段来进行处理。比如老项目在迁移的时候，大量的MISRA规则突然被打开，报警数量在瞬间就会上升。此时它们可以先被分类处理，影响安全和功能的报警被列为高优先级，风格类和历史遗留类的问题则被放到后续的整改中。与MISRA检查相关的选项在TASKING工具链中也是存在的，部分规则可以根据项目的策略被调整为警告或者错误。

　　三、TASKING编译报警增多后的稳妥整理方式

　　仅仅依靠临时关闭选项来处理报警是不行的。短期内虽然能编译通过，但是这并不代表工程的质量是稳定的。把选项、报警和代码整改分开来进行管理，才是更稳妥的做法。

　　1、对编译选项的基线进行建立

　　一份固定的编译选项基线最好在团队项目中被建立，其中应该包含工具链版本、芯片型号、优化等级、宏定义、include路径、库路径、链接脚本、报警等级和MISRA策略。后续在有人对选项进行修改时，改了什么、为什么改、影响了哪些配置都应该能被看出来。

　　2、大面积直接关闭报警的操作不可取

　　按类别来进行处理是更合理的方式。对于被确认没有风险的历史报警，局部抑制或者登记说明是可以被采用的；对于新引入的报警，在代码提交阶段将其解决是应该尽量做到的；对于影响功能和安全的报警，它们必须被当成缺陷来处理。特定warning作为error来处理也是被TASKING所支持的，这类设置在门禁规则里比较适用，但是对老工程不要在一开始就全面启用。

　　3、在每次调整之后进行一次完整构建

　　在编译选项被改完之后，只做增量编译是不被建议的。执行【Project】→【Clean】然后再重新Build是正确的做法。这样一来，旧的对象文件、旧的宏定义缓存以及旧的链接结果对判断的干扰就能被避免。

　　结论

　　TASKING编译选项设置的方法，以及由其导致报警增多时的排查步骤，其核心在于先把编译器、链接器、诊断规则和代码本身的边界分清楚。在设置的时候，从【Project】→【Properties】进入工程配置是必要的，Debug、Release或目标配置需要被分别核对。在报警增多之后，直接屏蔽的做法是不对的，变更时间、报警编号、触发文件和共同原因都需要被先查看。只有把编译选项基线、报警分类和代码整改流程固定下来，TASKING工程在后续的维护中才会更加稳定。