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:


#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里搞。某些保护只能在这个位置做


#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章 指令级并行和优化 https://www.zhihu.com/question/21823699/answer/292683540 我还需要向大神们学习 orz 通过实战来提高“精华”能力!


#54

感觉后端最难啊


#55

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


#56

共勉:君子不器(没有局限)越过山丘(挑战困难)


#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: