Link issues when writing my own pass using SVF

[zhaogang92]

I wrote a pass that leverages SVF, but I got some problems when running this pass.

Initially have the following line in my CMAKE file:
target_link_libraries(${PROJECT_NAME} LLVMSvf LLVMCudd ${llvm_libs})

This is similar to what I saw in the WPA tool of SVF. But this has the following linking issues. The reason is that WPA is an executable, and LLVMSvf and LLVMCudd are static libraries.
/usr/bin/ld: error: /mnt/data/Research/Library/SVF/build/lib/CUDD/libLLVMCudd.a(cuddExact.c.o): requires dynamic R_X86_64_PC32 reloc against 'free' which may overflow at runtime; recompile with -fPIC
/usr/bin/ld: error: /mnt/data/Research/Library/SVF/build/lib/CUDD/libLLVMCudd.a(cuddAnneal.c.o): requires dynamic R_X86_64_PC32 reloc against 'cuddNextLow' which may overflow at runtime; recompile with -fPIC
/usr/bin/ld: error: /mnt/data/Research/Library/SVF/build/lib/CUDD/libLLVMCudd.a(cuddLinear.c.o): requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC
/usr/bin/ld: error: /mnt/data/Research/Library/SVF/build/lib/CUDD/libLLVMCudd.a(cuddWindow.c.o): requires dynamic R_X86_64_PC32 reloc against 'cuddSwapInPlace' which may overflow at runtime; recompile with -fPIC
/usr/bin/ld: error: /mnt/data/Research/Library/SVF/build/lib/CUDD/libLLVMCudd.a(cuddGenetic.c.o): requires dynamic R_X86_64_PC32 reloc against 'st_lookup_int' which may overflow at runtime; recompile with -fPIC
...

So I changed the CMAKE file to:
target_link_libraries(${PROJECT_LIB_NAME} Svf Cudd ${llvm_libs})

This can successfully generate the .so file for my pass. However, when I ran the pass using opt, I got another error:
opt: CommandLine Error: Option 'bitcode-mdindex-threshold' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options.

Is anybody encounter the same problem?

[zhaogang92]

I tried merging my pass into SVF. If I did not change the CMAKE file, it got the below errors:
opt: CommandLine Error: Option 'bitcode-mdindex-threshold' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

If I changed the CMAKE file (This workaround solved the above problem in my other project):
target_link_libraries(Svf ${llvm_libs}) => target_link_libraries(Svf)

It got another error:
/mnt/data/Research/Library/llvm-6.0.0.src/build/bin/opt: symbol lookup error: /mnt/data/Research/Library/SVF/cmake-build-debug/lib/libSvf.so: undefined symbol: _ZN4llvm21DominanceFrontierBaseINS_10BasicBlockELb0EEC2Ev

Did anyone ever successfully use SVF as as PASS (not through the WPA tool)?

[yuleisui]

It seems to me that the error reflects that you didn't put the corresponding cpp files containing symbol "DominanceFrontierBase" in your cmake compilation.

[zhaogang92]

I figured out it. This symbol is from LLVM and I checked that is is included in the generated static library LLVMAnalysis, but it is a weak symbol. It seems other objects in that module do not use it, so it's not included in the text section of the generate .a file. I explicitly include it in the file list of add_library, so that it becomes defined in the library. Explicit class initialization for subclass of that class may also work.

[yuleisui]

Thanks for the update!

[yuleisui]

Is there any cmake issue in SVF for other users to avoid your problem? If so, please also make a pull request.

[zhaogang92]

No I did not change SVF for this problem. But when I try to integrate SVF into LLVM, I encountered some problems, I did not have time to figure out it yet.

[hongxuchen]

@zhaogang92 @yuleisui Here are my opinions about this issue.

1. For Svf.so, we would like it to be used as a loadable shared module and used like opt -load Svf.so. If we link the relevant libraries ${llvm_libs}, the module containing bitcode-mdindex-threshold (should be bitwriter, see http://llvm.org/doxygen/BitcodeWriter_8cpp_source.html) is statically loaded; but opt will always load this module dynamically once more (and this is the root cause). Therefore we should exclude linking ${llvm_libs} for Svf.so.
2. For LLVMSvf.a, the problem gets a bit complicated. We would like it to be statically linked by other targets, which can be either loadable shared libraries or executables. If the target is a loadable module, for similar reasons above, it has to exclude linking ${llvm_libs} to avoid the "registered more than once" error. If the target is an executable, LLVMSvf.a can be linked with or without ${llvm_libs}, since the system linker will always resolve the symbols correctly even when both LLVMSvf.a and the target executable link libraries inside {llvm_libs} twice. Therefore, it's better to also exclude linking ${llvm_libs} for LLVMSvf.a. Note that if LLVMSvf.a is supposed to be linked by shared libraries (including llvm loadable shared modules), it needs to be compiled with -fPIC (for CMake, something like set_property(TARGET LLVMSvf PROPERTY POSITION_INDEPENDENT_CODE ON)).

[kanads]

Hi. I'm trying to use the SABER, but had issues similar to OP when using opt. I followed @hongxuchen's advice (removing ${llvm_libs}) and it worked for me for Svf.so. However, the problem persists when working with the debug version.
[I'm using the latest version of SVF with LLVM7.]