[llvm-dev] Conflicts with custom passes

[Kihong Heo via llvm-dev]

I see. Thanks to  your help, I could proceed a lot.

I am wondering how out-of-tree LLVM pass is robust. I am building my custom pass on one machine and want to run this for other machines (e.g., Docker images).
I notice that LLVM IR’s OPCode is different from versions. Also it seems that type matching (e.g., if (llvm::CallInst *CI = llvm::dyn_cast<llvm::CallInst>(&I))) does not work well another machine. But I am not sure whether my guess is correct or not.
Do you have any idea or suggestion?

- Kihong

> 2019. 6. 28. 오후 7:27, Mehdi AMINI <joker.eph at gmail.com> 작성:
> 
> 
> 
> On Fri, Jun 28, 2019 at 4:21 PM Kihong Heo via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> You are right. Thanks!
> I fixed that one as well as some other issues.
> I built LLVM-8 with Debug + no-rtti. But it now has the following error:
> 
> Stack dump:
> 0.      Program arguments: clang-8 -cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -disable-free -main-file-name time-1.7.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -coverage-notes-file /home/khheo/project/parametric-symexe/test/toy1/time-1.7.gcno -resource-dir /home/khheo/project/llvm-8/build/lib/clang/8.0.1 -internal-isystem /usr/local/include -internal-isystem /home/khheo/project/llvm-8/build/lib/clang/8.0.1/include -internal-externc-isystem /usr/include/x86_64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -O0 -fdebug-compilation-dir /home/khheo/project/parametric-symexe/test/toy1 -ferror-limit 19 -fmessage-length 364 -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -load ../../trace-extractor/build/TracePass.so -o time-1.7.ll -x c /home/khheo/project/all/time-1.7.c -faddrsig
> 1.      <eof> parser at end of file
> 2.      Per-module optimization passes
> 3.      Running pass 'Unnamed pass: implement Pass::getPassName()' on module '/home/khheo/project/all/time-1.7.c'.
> …
> 
> What does "Running pass 'Unnamed pass: implement Pass::getPassName()' on module” mean?
> 
> It is just debugging on crashes, passes can override this method: https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Pass.h#L96 <https://github.com/llvm/llvm-project/blob/master/llvm/include/llvm/Pass.h#L96> to provide a more readable name.
> In practice if passes are registered it isn't needed I think.
> In any case this is not the cause of the crash, you can try running the clang -cc1 command in a debugger.
> 
> -- 
> Mehdi
> 
>  
> 
> - Kihong
> 
> 
> > On Jun 28, 2019, at 4:48 PM, Tim Northover <t.p.northover at gmail.com <mailto:t.p.northover at gmail.com>> wrote:
> > 
> > On Fri, 28 Jun 2019 at 21:18, Kihong Heo <kihong.heo at gmail.com <mailto:kihong.heo at gmail.com>> wrote:
> >> When I search for this issue on Google, it seems to be relevant to “RTTI”.
> > 
> > Yep, that's a typeinfo symbol.
> > 
> >> But as I know LLVM is built by default -fno-rtti. I also explicitly turned off it. Here is my cmake command:
> >> 
> >> $ cmake -DCMAKE_BUILD_TYPE=Debug -DLLVM_ENABLE_RTTI=OFF -DLLVM_ENABLE_PROJECTS=clang -G "Unix Makefiles"  ../llvm
> >> 
> >> Any thought?
> > 
> > My best guess is that your pass was built *with* RTTI (i.e. no
> > -fno-rtti) but LLVM without. A quick fix would be to switch to
> > -DLLVM_ENABLE_RTTI=ON, but longer term you may want to look into your
> > pass's build system.
> > 
> > Cheers.
> > 
> > tim.
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190629/f90262df/attachment-0001.html>