[llvm-dev] [cfe-dev] JIT doens't resolve address

陳韋任 via llvm-dev llvm-dev at lists.llvm.org
Thu Apr 20 06:53:11 PDT 2017


Redirect to llvm-dev list.

2017-04-20 21:43 GMT+08:00 via cfe-dev <cfe-dev at lists.llvm.org>:

> Hello LLVM-World,
>
> I was following the "Building a JIT in LLVM"-Tutorial and tried to load a
> normal main. My code is the following:
> class Jitter
> {
> private:
>   std::unique_ptr<TargetMachine> TM;
>   const DataLayout DL;
>   ObjectLinkingLayer<> ObjectLayer;
>   IRCompileLayer<decltype(ObjectLayer)> CompileLayer;
>
> public:
>   typedef decltype(CompileLayer)::ModuleSetHandleT ModuleHandle;
>
>   Jitter() : TM(EngineBuilder().selectTarget()), DL(TM->
> createDataLayout()),
>       CompileLayer(ObjectLayer, SimpleCompiler(*TM))
>   {printf("!");
>         llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr);
>   }
>
>   TargetMachine &getTargetMachine() { return *TM; }
>
>   ModuleHandle addModule(std::unique_ptr<Module> &&M) {
>   // Build our symbol resolver:
>   // Lambda 1: Look back into the JIT itself to find symbols that are
> part of
>   //           the same "logical dylib".
>   // Lambda 2: Search for external symbols in the host process.
>   auto Resolver = createLambdaResolver(
>       [&](const std::string &Name)
>       {
>                 printf("FLUSH :0\n");
>
>         if (auto Sym = CompileLayer.findSymbol(Name, false))
>           return Sym;
>         return JITSymbol(nullptr);
>       },
>       [](const std::string &S)
>           {
>                   printf("PLUSH :0\n");
>
>         if (auto SymAddr =
>               RTDyldMemoryManager::getSymbolAddressInProcess(S))
>           return JITSymbol(SymAddr, JITSymbolFlags::Exported);
>         return JITSymbol(nullptr);
>       });
>
>   // Build a singleton module set to hold our module.
>   std::vector<std::unique_ptr<Module>> Ms;
>   Ms.push_back(std::move(M));
>
>   // Add the set to the JIT with the resolver we created above and a newly
>   // created SectionMemoryManager.
>   return CompileLayer.addModuleSet(std::move(Ms),
>                                    make_unique<SectionMemoryManager>(),
>                                    std::move(Resolver));
> }
>
> JITSymbol findSymbol(const std::string Name) {
>   std::string MangledName;
>   raw_string_ostream MangledNameStream(MangledName);
>   Mangler::getNameWithPrefix(MangledNameStream, Name, DL);
>   printf("Tzearch for: %s\n\n", MangledNameStream.str());
>   return CompileLayer.findSymbol(MangledNameStream.str(), false);
> }
>
> void removeModule(ModuleHandle H) {
>   CompileLayer.removeModuleSet(H);
> }
>
> };
>
> And calling from main with:
>
> int main()
> {
>         llvm::InitializeNativeTarget();
>         llvm::InitializeNativeTargetAsmPrinter();
>         llvm::InitializeNativeTargetAsmParser();
>
>         llvm::LLVMContext context;
>         llvm::SMDiagnostic dia;
>
>         std::unique_ptr<llvm::Module> M = llvm::parseIRFile("./jit_main.
> ll", dia, context);
>         Jitter jit;
>         printf("Wuff?");
>         Jitter::ModuleHandle h = jit.addModule(std::move(M));
>         printf("KNUFF!\n");
>
>         printf("Kuchen! 0x%p\n", jit.findSymbol("main").getAddress());
>
>         system("PAUSE");
>         return 0;
> }
> The Code runs without a fail, but when the programm tries to resolve
> "main" the address is 0. The strange thing: the printf "FLUSH :0\n" and "PLUSH
> :0\n" are never called, so did the code never compiled? What I'm doing
> wrong?
>
> Kind regards
> Björn
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789
> Geschäftsführer: Hiroshi Kawamura, Dr Hiroshi Nakamura, Markus Bode, Heiko
> Lampert, Takashi Nagano, Takeshi Fukushima.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>


-- 
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170420/85c97745/attachment.html>


More information about the llvm-dev mailing list