在嵌入式项目切到Green Hills编译器之后，头一次做完整构建的时候，经常能看到大量的告警跳出来。要弄清楚Green Hills编译器告警太多到底该先处理哪些，不能只按它们冒出来的顺序一条一条去改，而是得先按风险的高低和影响的范围来分层。Green Hills Optimizing Compilers这套编译器本身就是给嵌入式场景用的，常用在那些对可靠性、性能还有代码质量要求比较高的项目里。告警本身虽然不等于错误，但它的出现往往就是在提醒你，代码里头可能藏着类型、初始化、转换或者可移植性方面的风险。

　　一、Green Hills编译器告警太多先处理哪些

　　当告警数量一下子堆得很高的时候，应该先挑那些真会影响到运行结果和内存安全的问题下手，然后再去管风格类和历史遗留类的提示。不要一上来就直接用屏蔽的方式把所有的告警都盖住，不然真正要命的缺陷也会跟着被埋进土里。

　　1、先处理可能改变运行结果的告警

　　排在前面的一般包括没被初始化的变量、函数缺了返回值、数组有越界的风险、指针类型对不上号、整数被截断、符号位的转换不太对劲，还有函数声明跟别处不一致。这些东西如果放着不管，在不同优化等级、不同芯片或者换过编译选项以后，表现出来的毛病很可能完全不一样。

　　2、接着处理接口和声明不一致的告警

　　头文件里的声明跟源文件里的实现对不上、函数原型压根没写、extern出去的类型不一样、枚举值跟整数混着用，这些都应该尽早修干净。在嵌入式项目里面，接口一旦出了问题，可是会直接影响到函数调用约定、参数传递，甚至内存访问，把程序搞得莫名其妙跑飞。

　　3、再往下就处理跟可移植性有关的告警

　　Green Hills的工程经常要跑在好几个不同的平台和编译器上，如果你在代码里对类型的长度做了假设、用了比较生硬的强制类型转换、对结构体的对齐或者大小端有依赖，这些以后都可能拖累到后续的移植工作。OpenSSF的编译器加固指南里也强调过，编译器选项可以帮着把可靠性和安全性往上提一提。

　　4、最后再去统一收拾风格类和低风险的告警

　　像没有被用到的变量、没被用上的参数、局部名字把外头的给遮住了，还有注释那一类的提示，都是可以往后排的。只不过公共头文件和高频调用的模块里面，这种低风险告警也别让它们堆得太久，因为它们会在每一次构建日志里反复刷屏，看着太碍事。

　　二、Green Hills编译器告警过滤规则怎么设置

　　在动手去过滤告警以前，先要想好哪些告警是可以被允许过滤掉的，哪些又是必须老老实实去修掉的。过滤的规则应该写进项目构建的配置文件里面去，而不能让每个人都在本地环境里随意去关掉它。

　　1、按项目标准去设置告警等级

　　如果用的是MULTI IDE，那就可以在Project或者Target的Build Options里面来调整编译器告警的那些选项。Green Hills MULTI本身就是一套集成开发环境，专门拿来构建、调试和优化嵌入式应用的。团队内部应该保存好统一的工程配置，不能让大家在本地构建和CI构建的时候，跑出两套不一样的告警等级来。

　　2、按照告警编号或者类别去做过滤

　　具体到底要怎么过滤，当然还是要以当前Green Hills版本的手册为准。常见的思路是尽量保留高风险的那些诊断信息，只对第三方库、已经改不动的老代码，或者是已经确认过确实没有影响的告警去设置抑制。千万不能拿那种“一键关闭全部告警”的方式来代替自己该做的分析。

　　3、把外部代码单独拎出来处理

　　芯片SDK、RTOS、第三方的协议栈，还有供应商给的那些库里面的告警，最好是放到单独的目录里，用一套单独的规则去对付它们。项目自己写的代码可以保持一个比较严的告警策略，而对外部代码，则可以按风险评估的结果去做有限度的过滤，免得构建日志被那些外来的文件刷得没法看。

　　4、在CI里头保留一道新增告警的门禁

　　对于历史遗留的告警，可以建一条基线存着，但是对于新加进来的告警，就一定要尽可能把它给拦住。已经存在的遗留问题可以先分批次去整改，但是新提交的代码不能再继续往里面增加同类型的问题，只有这样告警数量才会一步一步往下降。

　　三、Green Hills告警清理怎么避免误过滤

　　给告警做过滤，目的可不是为了让构建日志看起来干干净净，而是为了让那些真正值得下手去改的问题能够更加显眼。规则设好了以后，还是得隔一段时间就去复查一遍。

　　1、把每一条过滤的原因都给记下来

　　每加一条过滤规则，都要写清楚它对应的是哪个告警编号、这条规则用到了哪个路径上、当初为什么要把它给过滤掉，还要标上是谁做的这个决定。比如是因为第三方文件暂时不方便去动，还是碰到了编译器的误报，又或者是硬件寄存器的访问本来就要求那种特殊写法。光是写一个“忽略”，那以后根本就没有复核的价值。

　　2、把过滤的范围先圈得小一点

　　如果可以只按文件来过滤，那就不要对整个项目去过滤；要是可以只压住单独的一条告警，那就不要一巴掌把整整一类告警全给拍掉。范围缩得越小，误伤到真实问题的概率也就跟着越低。

　　3、定时去翻一翻那些过滤的清单

　　等升级完编译器、换过芯片平台，或者把模块重构了一轮以后，原来那套过滤的理由很可能早就已经站不住脚了。可以趁着每一个版本节点，去把过滤的规则抽出来检查一遍，把那些已经不再需要的抑制项给删掉。

　　4、把静态分析和代码评审也拉上一起看

　　编译器的告警，说到底也只能覆盖到一部分问题，像内存的生命周期、并发访问时候的冲突、复杂控制流里面的暗坑，还有跟安全规则有关的东西，这些还是得靠静态分析工具，再加上人来做的代码评审，一块儿去把关。

　　总结

　　Green Hills编译器告警太多的话，建议按运行风险、接口一致性、可移植性和低风险提示这样四层去分开处理。给Green Hills编译器设置告警过滤规则的时候，重点是把整个项目的告警等级给统一起来，然后按照告警编号、所在路径还有代码来源去有节制地做过滤，同时也要在CI里面把新增的告警给挡在门外。每一条过滤规则都应该有原因、有范围，也要有人回头去复查，千万别让它变成了把真实问题给藏起来的工具。