Llvm “防”反向 pass

干货分享
41

谢。我目前Transform的Pass是给IPO加了依赖然后放在PassManagerBuilder里的。CG有类似的方式增加依赖来直接复用现有的Transform模块来避免自己的pass散落在源码树里各个角落么

42

Transform里的就像你说的可以通过addRequired来添加依赖，例如：https://github.com/ScaffCC/scaff-llvm/blob/master/lib/Transforms/Scaffold/GenQASM.cpp#L158

CodeGen里是通过INITIALIZE_PASS_DEPENDENCY来添加依赖，例如：https://github.com/xiangzhai/llvm/blob/riscv/lib/CodeGen/RegAllocGraphColoring.cpp#L151

但是我的风格是：如果真的决定要做RA，就一定要100%投入，替代掉LLVM现在的Greedy（从LLVM 3.0之后引入的Greedy，替代了Chris的LinearScan） https://github.com/xiangzhai/llvm/blob/riscv/lib/CodeGen/RegAllocGreedy.cpp 要么就不做，继续使用没有GCC的“图染色”优秀的Greedy算法，所以我修改了lib/CodeGen/CodeGen.cpp等文件，“希望”有朝一日能替代掉Greedy吧，希望 :slight_smile:

1 个赞
43

额，我在clang CodeGen的时候尝试修改的IR的函数名

auto Result = Manglings.insert(std::make_pair(Str, GD));

clang生成IR函数名的时候会保存到Manglings中，只要把这个Str改了整个文件的函数名就都混淆了

44

我建议在IR层做比较好，因为有一个项目DragonEgg 可以GCC FrontEnd → GIMPLE → LLVM IR，那么就可以把Clang前端不支持的语言：比如fortran翻译成LLVM IR，然后统一在IR层做混淆，这样工作量也是最小的 :slight_smile:

45

主要目前我们做的混淆是基于libclang的，好处是debug方便，支持嵌入式方便
不过以后估计是要往IR跑了。不跑下一步的swift都不知道咋支持。

46

这就体现出在IR层做的好处了呀 :slight_smile: 不用关心具体的语言，不管是C、C++、OC、Swift、Fortran、Scaffold量子计算语言，都可以翻译成LLVM IR，IR层做变换的实战可以看ScaffCC项目。

47

嗯，我们也准备先在开源上支持下IR，试试水
第一步先把OLLVM重写了:roll_eyes:

48

不是基于clang做相比IR难道有什么好处么

49

另外即使非要这么做我相信用libTooling遍历AST里的Decl也是比硬改代码更好的主意

50

好处一个是方便debug。混出问题了前后一对比就知道是混淆出的问题还是本身代码的问题
另一个是对嵌入式环境的支持，因为是源对源的混淆，输出的也是C代码，基本不用考虑嵌入式编译环境问题最多多支持几个attribute
事实上我们就是用的libTooling构造的工具，那个在clang里硬改的是我自己的尝试罢了。
不过clang本身的bug也是有的，尤其是AST到源码的Printer，bug巨多，还没人管，我们一直用的是自己维护的clang

51

还有一点，讲道理的话在clang做出来的强度是要比IR上好一些的。
加不透明谓词也方便，Printer的时候直接打出来就好，不用构造指令
插各种防调、完整性校验的代码，也巨方便

52

meh我还是喜欢IR和CodeGen里搞。某些保护只能在这个位置做

1 个赞
53

Zhang大已经深入到《编译原理》的第6章 中间代码（IR）生成、第8章 代码生成（CodeGen），大大的赞！

为什么说IR层重要，是因为LLVM项目的历史，在一开始LLVM工具链并没有FrontEnd，用的是llvm-gcc 以及后来的DragonEgg 都是直接使用GCC FrontEnd，不是因为Chris Lattner那时撸不出Clang，而是因为《编译原理》的“精华”在第9章 在IR层的Target无关优化，对应到LLVM就是lib/Transform 第10、11章 指令级并行和优化 指令级并行，线程级并行，数据级并行区别？线程的概念是什么？ - 知乎 我还需要向大神们学习 orz 通过实战来提高“精华”能力！

54

感觉后端最难啊

55

给上游报Clang的BUG的时候可以Cc给我lesliezhai@llvm.org.cn 我会负责的！

56

共勉：君子不器（没有局限）越过山丘（挑战困难）

2 个赞
57

哈哈，主要Printer这块没啥人用，据说以前给clang报过bug，写过邮件，大半年没动静也就不了了之了，我们自己维护了

58

方案都是有利有弊嘛，没有完美的

59

dalao给LLVM上流丢个pull呗。
BasicBlock默认的FindInsertpt是不是应该考虑到EH的LandingPad之类的

60

LLVM使用SVN进行版本控制，LLVM的开发流程是这样的：如果发现了BUG，欢迎PR https://bugs.llvm.org/ 如果有新需求，欢迎ML http://lists.llvm.org/pipermail/llvm-dev/ 如果希望patch被合并进入上游SVN仓库，欢迎code review https://reviews.llvm.org/ 获得LGTM后，会由maintainer（成为GCC maintainer有多难）合并到上游仓库，当然会留下作者你的名字 如果你贡献的patch多了，并严格遵守LLVM开发者政治，坚决不破坏开发流程，Chris Lattner就会给你SVN仓库的提交权限，能力越大责任越大，依然遵守LLVM开发流程，当patch获得LGTM后，再提交到SVN仓库 :slight_smile:

2 个赞