解决TI的CCS在安装了维响加密软件的电脑上编译C/C++代码失败问题

背景

现在很多企业会对办公电脑上的文件进行加密，特别是.doc .xls等设计文档 .c .cpp .h等源代码，会被重点照顾。另外加密软件又会给处理这些文件的正经软件（office的word.exe、Visual Studio的cl.exe）开启自动解密白名单。

CCS是TI开发的一款IDE，面向C6000等DSP芯片的软件开发。我司前一段时间开启了.c .cpp .h等源代码的加密，结果发现用CCS编译C代码失败。

解决过程

看来需要将CCS的一些处理程序也添加到白名单

开启cl6x.exe的自动解密

了解到CCS的编译器的exe文件名是cl6x，于是请IT专员在加密服务器上添加如下规则：

测试，C代码编译通过。

但是第二天改了个.h文件后，又出现编译不过的现象了。

定位修改.h文件后编译仍然出错的问题

跟IT专员确认没动规则，于是决定缩小范围，先构造一个demo工程编译，不过，再在命令行下直接调用cl6x编译，也不过。

注意到cl6x同目录下还有很多exe，会不会是cl6x调用别的exe执行失败但是报错的时候说是自己失败了呢？查看C6000的手册，发现cl6x确实是个门面程序（门后面有很多个实际干活的程序听它调度）

所以需要找到cl6x实际调用哪个程序，查找TMS320C6000 Optimizing Compiler 等文档，没找到cl6x同级目录下那些exe到底是干啥的。

想到可以将cl6x放到一个单独的目录，如果它调了别的exe，那一定会找不到，如果报错，我们不就知道调的是哪个exe了吗？说干就干

第一次调用提示找不到acp6x，而不是报错c文件内容，说明首先处理c文件的是acp6x命令，只是acp6x处理失败后，cl6x说是自己处理失败，导致我走了好多弯路。

于是将acp6x也拷贝到前述目录，这次复现故障（上图第二个命令行），也印证了猜想。

开启acp6x.exe的自动解密

请IT专员将acp6x也添加到白名单

这下编译通过了！

定位修改cpp文件后编译仍然出错的问题

这次仍然是在单独目录下编译，没复现line 1故障，而是提示别的问题

当时以为工具链没问题，就往别的地方猜想，比如文件是java.exe读取的，而java.exe没开启自动解密，但是无凭无据光靠猜想就让IT专员修改服务器规则，总觉得不太体面，于是再次观察CCS的console打印跟cmd提示符打印的区别，想到二者的命令行参数不一样，于是给cmd命令行传递跟CCS的console一样的命令行参数，这下果然发现端倪了！

用CCS完整命令行编译cpp会发现漏了acpia6x命令，看来cl6x在编译cpp文件时会额外调用一个叫acpia6x.exe的文件，猜测是做进一步的预处理的，当它读取cpp文件失败（因为加密软件没给它自动解密），就会告诉cl6x自己在处理第一行时失败，最后cl6x报告说自己处理第一行失败。

开启acpia6x.exe的自动解密

补上acpia6x命令的自动解密后，cl6x成功编译出obj文件

总结

1. 要为加密源文件找到所有会处理它们的exe，而不仅仅是门面程序。
2. 只要开启cl6x acp6x acpia6x三个exe的自动解密即可，其他exe因为不涉及obj文件的生成而幸免于麻烦
3. TI应该说明下cl6x的调度实现，就像GNU告诉我们gcc会调用cpp gas等