自定义llvm opt的未定义符号? [英] undefined symbol for self-built llvm opt?

查看:210
本文介绍了自定义llvm opt的未定义符号?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我写了一个简单的llvm插件,要求 opt 加载xxx.so文件并运行ModulePass.奇怪的是,当我使用debopt(例如,来自apt-get的包,我们称它为opt-3.7)时,该插件可以正常工作(缺点是它是 Release >构建);但是,当我使用 opt 建立自己(简化称为opt)时,它会经常抱怨:

I write a simple llvm plugin pass that requires opt to load xxx.so file and run a ModulePass. The strange thing is that when I use deb package opt (e.g., from apt-get, let's call it opt-3.7), the plugin works fine (the drawback is that it is a Release build); however when I use the opt I build myself (simplify call it opt), it frequently complains:

Error opening 'xxx.so': xxx.so: undefined symbol: _ZNK4llvm12FunctionPass17createPrinterPassERNS_11raw_ostreamERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

使用c++filt我知道opt找不到llvm::FunctionPass::createPrinterPass(llvm::raw_ostream&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const.

这是一个很大的奇怪,因为我没有在通行证中使用任何FunctionPass;但让我们忽略这一点,然后继续.

It's a big strange since I didn't use any FunctionPass in the pass; but let's ignore this and continue.

然后我检查了ldd opt

linux-vdso.so.1 =>  (0x00007ffd5c1ce000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f16a90d3000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f16a8ea9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f16a8c8c000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f16a8a72000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f16a86ef000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f16a83e6000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f16a81d0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f16a7e06000)
/lib64/ld-linux-x86-64.so.2 (0x00005645f6210000)

ldd opt-3.7

linux-vdso.so.1 =>  (0x00007ffc51bc0000)
libLLVM-3.7.so.1 => /usr/lib/x86_64-linux-gnu/libLLVM-3.7.so.1 (0x00007fec3f725000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fec3f3a2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fec3efb1000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fec3ed97000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fec3eb79000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fec3e971000)
libedit.so.2 => /usr/lib/x86_64-linux-gnu/libedit.so.2 (0x00007fec3e739000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fec3e50f000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fec3e30b000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fec3e002000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fec3ddeb000)
/lib64/ld-linux-x86-64.so.2 (0x000055bad2080000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007fec3dbd6000)

我想,区别是这样的文件libLLVM-3.7.so.1.

The difference, I guess, is the so file libLLVM-3.7.so.1.

那我没看错吗?

顺便说一句,我的llvm是不带w/o和带-DLLVM_BUILD_LLVM_DYLIB=1的,都具有未定义的符号问题.

BTW, my llvm was built w/o and w/ -DLLVM_BUILD_LLVM_DYLIB=1, both has the undefined symbol issue.

推荐答案

在CLANG 3.9中使用LLVM插件时,我们有完全相同的错误.然后,我们在这里找到解决方案: https://github.com/klee/klee/issues/336

We had exactly the same error when using LLVM plugin with CLANG 3.9. We then found the solution here: https://github.com/klee/klee/issues/336

解释是用于LLVM的libstdc ++的ABI与您的插件不同.要解决此问题,您需要使用以下标志"-D_GLIBCXX_USE_CXX11_ABI = 0"重新编译您的插件.

The explanation is that ABI for libstdc++ used for LLVM and your plugin is different. To solve this problem you need to recompile your plugin with the following flag "-D_GLIBCXX_USE_CXX11_ABI=0".

以示例方式检查此Makefile中的LLVM插件: https://github.com/SamAinsworth/reproduce-cgo2017-paper/blob/master/package/plugin-llvm-sw-prefetch-pass/Makefile

Check this Makefile for LLVM plugin as example: https://github.com/SamAinsworth/reproduce-cgo2017-paper/blob/master/package/plugin-llvm-sw-prefetch-pass/Makefile

这篇关于自定义llvm opt的未定义符号?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆