opt can't load pass

[posutsai]

Hi I was trying to build LLVM from source and I already tried llvmorg-10.0.0-rc3 and llvmorg-11-init two versions. Previously the LLVM tool I used was installed from ubuntu apt package tool and my code works very well with it. However, when I switch to the opt that was built from source, it always output following error message. I am pretty sure the issue doesn't come from the loaded pass shared object file itself because opt prints same error after I load the HelloPass from the tutorial.

opt: CommandLine Error: Option 'debug-pass' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

I simply follow the instructions from the official website. Here's how I build LLVM.

git clone https://github.com/llvm/llvm-project.git
mkdir build && cd build
cmake -G "Unix Makefiles" -DLLVM_ENABLE_PROJECTS="clang" -DCMAKE_BUILD_TYPE="Release" ../llvm
make && make install

After some searching on Google, I doubt the issue comes from version conflict. Yet opt outputs the same message when I remove all of other version on my server. Thanks for your help and please let me know if the further information is needed.

Referring to these two similar issues,

1. LLVM linking: CommandLine Error: Option 'help-list' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options
2. "opt: CommandLine Error: Option 'disable-symbolication' registered more than once!" when building with dg library
   I think it's necessary to show how I compile the Pass source code and input it into opt.

clang-10 -fPIC -c HelloPass.cpp -o HelloPass.o `llvm-config --cxxflags`
clang-10 -shared -o HelloPass.so HelloPass.o `llvm-config --ldflags --libs --system-libs`
opt -load HelloPass.so -hello-pass -S < source.ll > /dev/null

[jdoerfert]

By default, LLVM will build shared libraries. Pre-build packages usually come with statically linked libraries. Your problem seems to be that you have the static initializer of the debug-pass flag run twice. I guess it is because of the shared vs statically linkage of llvm libraries. You can either tell your your source llvm to link everything statically or you update your build process of the pass. I imagine llvm-config output to be different in the source build and you not needing all libraries you link in this way anyway.

[posutsai]

Thanks for your reply. The error message appears even when I try to build my pass in a completely new docker container. I will try the former solution first. However, regarding to the binary file size of the output pass, I really want to have dynamic linkage. As for latter solution, do you mean that some of the flags in comes from llvm-config --ldflags --libs --system-libs are conflict to each other? If that's the case, as my development goes on I strongly doubt I'll meet more conflict in the future. By the way, just for double-check, if I want to make all of the llvm lib compile to archive mode, the configuring option is to set BUILD_ARCHIVE, is that right?

[posutsai]

I rebuild LLVＭ with BUILD_ARCHIVE seems like the error remains unsolved.

[jdoerfert]

what is the output of llvm-config --ldflags --libs --system-libs?

[posutsai]

Following is the output of llvm-config --ldflags --libs --system-libs.

-L/usr/local/lib
-lLLVMXRay -lLLVMWindowsManifest -lLLVMTableGen -lLLVMSymbolize -lLLVMDebugInfoPDB -lLLVMOrcJIT -lLLVMOrcError -lLLVMJITLink -lLLVMObjectYAML -lLLVMMCA -lLLVMLTO -lLLVMPasses -lLLVMCoroutines -lLLVMObjCARCOpts -lLLVMLineEditor -lLLVMLibDriver -lLLVMInterpreter -lLLVMFuzzMutate -lLLVMMCJIT -lLLVMExecutionEngine -lLLVMRuntimeDyld -lLLVMDWARFLinker -lLLVMDlltoolDriver -lLLVMOption -lLLVMDebugInfoGSYM -lLLVMCoverage -lLLVMXCoreDisassembler -lLLVMXCoreCodeGen -lLLVMXCoreDesc -lLLVMXCoreInfo -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMX86Desc -lLLVMX86Utils -lLLVMX86Info -lLLVMWebAssemblyDisassembler -lLLVMWebAssemblyCodeGen -lLLVMWebAssemblyDesc -lLLVMWebAssemblyAsmParser -lLLVMWebAssemblyInfo -lLLVMSystemZDisassembler -lLLVMSystemZCodeGen -lLLVMSystemZAsmParser -lLLVMSystemZDesc -lLLVMSystemZInfo -lLLVMSparcDisassembler -lLLVMSparcCodeGen -lLLVMSparcAsmParser -lLLVMSparcDesc -lLLVMSparcInfo -lLLVMRISCVDisassembler -lLLVMRISCVCodeGen -lLLVMRISCVAsmParser -lLLVMRISCVDesc -lLLVMRISCVUtils -lLLVMRISCVInfo -lLLVMPowerPCDisassembler -lLLVMPowerPCCodeGen -lLLVMPowerPCAsmParser -lLLVMPowerPCDesc -lLLVMPowerPCInfo -lLLVMNVPTXCodeGen -lLLVMNVPTXDesc -lLLVMNVPTXInfo -lLLVMMSP430Disassembler -lLLVMMSP430CodeGen -lLLVMMSP430AsmParser -lLLVMMSP430Desc -lLLVMMSP430Info -lLLVMMipsDisassembler -lLLVMMipsCodeGen -lLLVMMipsAsmParser -lLLVMMipsDesc -lLLVMMipsInfo -lLLVMLanaiDisassembler -lLLVMLanaiCodeGen -lLLVMLanaiAsmParser -lLLVMLanaiDesc -lLLVMLanaiInfo -lLLVMHexagonDisassembler -lLLVMHexagonCodeGen -lLLVMHexagonAsmParser -lLLVMHexagonDesc -lLLVMHexagonInfo -lLLVMBPFDisassembler -lLLVMBPFCodeGen -lLLVMBPFAsmParser -lLLVMBPFDesc -lLLVMBPFInfo -lLLVMAVRDisassembler -lLLVMAVRCodeGen -lLLVMAVRAsmParser -lLLVMAVRDesc -lLLVMAVRInfo -lLLVMARMDisassembler -lLLVMARMCodeGen -lLLVMARMAsmParser -lLLVMARMDesc -lLLVMARMUtils -lLLVMARMInfo -lLLVMAMDGPUDisassembler -lLLVMAMDGPUCodeGen -lLLVMMIRParser -lLLVMipo -lLLVMInstrumentation -lLLVMVectorize -lLLVMLinker -lLLVMIRReader -lLLVMAsmParser -lLLVMFrontendOpenMP -lLLVMAMDGPUAsmParser -lLLVMAMDGPUDesc -lLLVMAMDGPUUtils -lLLVMAMDGPUInfo -lLLVMAArch64Disassembler -lLLVMMCDisassembler -lLLVMAArch64CodeGen -lLLVMCFGuard -lLLVMGlobalISel -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMDebugInfoDWARF -lLLVMCodeGen -lLLVMTarget -lLLVMScalarOpts -lLLVMInstCombine -lLLVMAggressiveInstCombine -lLLVMTransformUtils -lLLVMBitWriter -lLLVMAnalysis -lLLVMProfileData -lLLVMObject -lLLVMTextAPI -lLLVMBitReader -lLLVMCore -lLLVMRemarks -lLLVMBitstreamReader -lLLVMAArch64AsmParser -lLLVMMCParser -lLLVMAArch64Desc -lLLVMMC -lLLVMDebugInfoCodeView -lLLVMDebugInfoMSF -lLLVMBinaryFormat -lLLVMAArch64Utils -lLLVMAArch64Info -lLLVMSupport -lLLVMDemangle
-lrt -ldl -lpthread -lm

After several attempt yesterday, I consider I make some progress. I guess the root cause of the issue may come from how I register the pass. I attach the simplified implementation of my pass as below for reference.

  struct MyPass : public ModulePass {
    static char ID;
    MyPass() : ModulePass(ID) { }
    bool runOnModule(Module &M) override {
    // implementation here ....
      return true;
    }
  };

char PthreadScopeDetectPass::ID = 0;
static RegisterPass<MyPass> X("my-pass", "This is my pass", false, false);

After I read the blog, I switch how I register the pass and error message disappear. I copy the code snippet in the blog below. Thus I would try to use modern PassManager to register my pass and try to load it with opt again.

static void registerMyPass(const PassManagerBuilder &,
                           PassManagerBase &PM) {
    PM.add(new MyPass());
}
static RegisterStandardPasses
    RegisterMyPass(PassManagerBuilder::EP_EarlyAsPossible,
                   registerMyPass);

$ clang -Xclang -load -Xclang mypass.so ...

[posutsai]

I think I solve the opt loading issue and I refer to the video and the repo. I confirm that I should use the newer version pass register and load it with corresponding command line option. Thanks you @jdoerfert. I'll close the issue feel free to reopen it if you think it's necessary.