Codecov Report

Attention: Patch coverage is 30.00000% with 14 lines in your changes missing coverage. Please review.

Project coverage is 63.67%. Comparing base (9efda8a) to head (d25a348).
Report is 2 commits behind head on master.

@@            Coverage Diff             @@
##           master    #1697      +/-   ##
==========================================
- Coverage   63.70%   63.67%   -0.04%     
==========================================
  Files         244      244              
  Lines       25962    25988      +26     
  Branches     4565     4581      +16     
==========================================
+ Hits        16539    16547       +8     
- Misses       9423     9441      +18     

Thanks for the contribution. Could you split this pull request into two?

1. Build system
2. All others

I had a quick look at 2, all look good, and should be ready to merge.

1 looks a bit complicated and I will have to go through it separately.

Cheers

Thanks for the contribution. Could you split this pull request into two?

Sure, give me a bit to figure out what the easiest way to do this would be!

I had a quick look at 2, all look good, and should be ready to merge.

Great, happy to hear!

1 looks a bit complicated and I will have to go through it separately.

Makes sense. I did make sure to not break any backwards compatibility; all current ways of using SVF should continue to work unchanged. The only difference is that the exported CMake package now properly handles relocatability and dependency inheritance.

For example, the current CMake package doesn't properly expose dependencies and necessary ABI flags on the actual targets. As a result, linking against SVF's package after finding system instances (e.g., with find_package(SVF)) can still experience issues with this.

For example, say I want to use system-wide installations of Z3 & LLVM to build & link SVF against. I could install Z3 & LLVM like this:

# Z3 from official Ubuntu repositories
> sudo apt install z3 libz3-4 libz3-dev

# Ubuntu 24.04 (Noble) has LLVM-16 in the official repos as well
> sudo apt install llvm-16 llvm-16-dev llvm-16-tools \
    clang-16 libclang-16-dev libclang-rt-16-dev \
    lld-16 liblld-16 liblld-16-dev \
    ...

This would install these libraries in /usr/... and into the default paths such that any CMakeLists.txt script could do find_package(Z3) and find_package(LLVM) to find their CMake packages. To link against them --- and automatically inherit all required dependencies, ABI flags, etc. --- one can simply call target_link_libraries(myLib PRIVATE libz3).

These changes support using SVF in the same way. For example, I can build & install SVF globally like this:

> git clone https://github.com/SVF-tools/SVF.git ./SVF
> cd SVF
> cmake -S ./ \
    -G "Ninja" \
    -B Release-build \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_INSTALL_PREFIX=/usr/local \
    -DSVF_ENABLE_ASSERTIONS=ON \
    -DSVF_EXPORT_DYNAMIC=ON \
    -DBUILD_SHARED_LIBS=ON \
    -DSVF_DEBUG_INFO=ON \
    -DSVF_USE_LLD=ON
> cmake --build Release-build
> cmake --install Release-build [--install-prefix=/some/other/prefix]

This would install SVF's headers, CMake package, etc. to the chosen prefix so that the tools end up in places like /usr/local/bin/wpa and /usr/local/lib/libSvfCore.so. If I now wanted to use this global SVF instance in another project, I could simply find & link it in the same way SVF finds LLVM and Z3:

// File: CMakeLists.txt:

cmake_minimum_required(VERSION 3.28)
set(CMAKE_EXPORT_COMPILE_COMMANDS ON)

project(Foo CXX)
add_executable(foo foo.cpp)
find_package(SVF 3.0 REQUIRED CONFIG)
target_link_libraries(foo PRIVATE SVF::SvfCore SVF::SvfLLVM)
install(TARGETS foo RUNTIME DESTINATION bin)

// File: foo.cpp:

#include <MSSA/SVFGBuilder.h>
#include <SVF/Graphs/SVFG.h>
#include <SVF/SVF-LLVM/LLVMModule.h>
#include <SVF/SVF-LLVM/SVFIRBuilder.h>
#include <SVF/Util/CommandLine.h>
#include <SVF/Util/Options.h>
#include <SVF/WPA/Andersen.h>

#include <cstdlib>
#include <string>
#include <vector>

using namespace llvm;
using namespace std;
using namespace SVF;

int main(int argc, char **argv) {
  std::vector<std::string> modNameVec = OptionBase::parseOptions(
      argc, argv, "bitcodes", "[options] <bitcode...>");

  if (Options::WriteAnder() == "ir_annotator")
    LLVMModuleSet::preProcessBCs(modNameVec);
  LLVMModuleSet::buildSVFModule(modNameVec);

  SVFIR *pag = SVFIRBuilder().build();
  Andersen *ander = AndersenWaveDiff::createAndersenWaveDiff(pag);
  SVFG *svfg = SVFGBuilder().buildFullSVFG(ander);

  svfg->dump("input");

  AndersenWaveDiff::releaseAndersenWaveDiff();
  SVF::LLVMModuleSet::releaseLLVMModuleSet();
  SVFIR::releaseSVFIR();
  llvm::llvm_shutdown();

  return EXIT_SUCCESS;
}

I could then build, install, and run my tool like this:

> cmake -G "Ninja" -B build
> cmake --build build
> cmake --install build --prefix $(pwd)/install
> ./install/bin/foo some/example/bitcode.bc

The find_package(SVF) snippet finds the SVF CMake package. Internally, this package defines its dependencies, but also exposes its dependencies' dependencies (e.g., ABI flags required by the specific LLVM instance used, like -fno-rtti). Consequently, to use SVF, I don't need to also find LLVM and/or Z3 and link against them — CMake resolves that based on SVF's package. This also works for non-system wide installations of SVF (e.g., installed to ~/SVF/install/...) by setting the environment variable $SVF_DIR or passing it as a search path to the find_package(SVF HINTS <path>) invocation.

Of course, since the Release-build tree still exists as it did before, finding & linking against SVF how most test cases and examples do currently is still supported. Moreover, while headers are now cleanly installed into <prefix>/include/SVF/..., using the headers without the prefix (e.g., #include <WPA/Andersen.h>) is still possible (this is also exposed by the CMake package implicitly).

Moreover, after the find_package(SVF) call, its configuration variables become available, so a user can directly use CMake variables like ${SVF_USE_PIC} to check whether SVF was built with/without PIC, ${SVF_BUILD_TYPE} to check the used build type, or install paths (even when the installation prefix is changed after CMake configuration (i.e., during installation with cmake --install <build_dir> --prefix=some/new/install/prefix) like ${SVF_INSTALL_BINDIR} or ${SVF_INSTALL_INCLUDEDIR}.

Moreover, this keeps the dependencies "separate", ensuring only the SvfCore library depends on LLVM. In the future, this could easily be modified to ensure LLVM needn't be found if someone only wants to use & link against SvfCore (but not SvfLLVM).

I hope this clarifies the changes & use-case a bit more! As I said, I'd be happy to update the Wiki page to describe how to build, install, and use SVF and its dependencies like this, as well as write a new Wiki page describing how to use SVF within the default LLVM clang pass-pipeline! Would you still like me to split this pull request (no problem), or should I leave it combined if this makes enough sense to merge as-is?

Rebased from the current upstream's head to make merging easier. @yuleisui, let me know if you'd still like me to separate this pull request or if my previous comment sufficiently clarified my intent/use-case and you want to merge it as-is!

Rebased from the current upstream's head to make merging easier. @yuleisui, let me know if you'd still like me to separate this pull request or if my previous comment sufficiently clarified my intent/use-case and you want to merge it as-is!

Thanks, and could you separate the pull request? I can merge your "non-Build System" one first.