search for: getnamewithprefix

...In llvm 4.0 the MCJIT::getFunctionAddress function return 0 (a null address) when the symbol is not found : *uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); } return findSymbol(MangledName, CheckFunctionsOnly).getAddress();}* Now with the current implementation (llvm 5.0 rc1 tag) : *uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string Mangled...

...sual name", it will disable name mangling if you are >> > lucky. A leading \1 is LLVM's way of saying: leave this name alone! >> >> Seems like I'm out of luck - the @<n> suffix is added >> (AddFastCallStdCallSuffix) in the GlobalValue >> Magnler::getNameWithPrefix overload, without paying respect to whether >> the name originally had a '\1' prefix or not. >> >> Should this be changed? >> >> David >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu...

...ed? > if you use "\1" + "usual name", it will disable name mangling if you are > lucky. A leading \1 is LLVM's way of saying: leave this name alone! Seems like I'm out of luck - the @<n> suffix is added (AddFastCallStdCallSuffix) in the GlobalValue Magnler::getNameWithPrefix overload, without paying respect to whether the name originally had a '\1' prefix or not. Should this be changed? David

...t;\1" + "usual name", it will disable name mangling if you are > > lucky. A leading \1 is LLVM's way of saying: leave this name alone! > > Seems like I'm out of luck - the @<n> suffix is added > (AddFastCallStdCallSuffix) in the GlobalValue > Magnler::getNameWithPrefix overload, without paying respect to whether > the name originally had a '\1' prefix or not. > > Should this be changed? > > David > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu...

...will disable name mangling if you are >>> > lucky. A leading \1 is LLVM's way of saying: leave this name alone! >>> >>> Seems like I'm out of luck - the @<n> suffix is added >>> (AddFastCallStdCallSuffix) in the GlobalValue >>> Magnler::getNameWithPrefix overload, without paying respect to whether >>> the name originally had a '\1' prefix or not. >>> >>> Should this be changed? >>> >>> David >>> _______________________________________________ >>> LLVM Developers mailing list &gt...

...ostream.h" namespace llvm { namespace orc { @@ -77,6 +79,24 @@ public: return LMH->Resources; } + static std::string mangle(StringRef Name, const DataLayout &DL) { + std::string MangledName; + { + raw_string_ostream MangledNameStream(MangledName); + Mangler::getNameWithPrefix(MangledNameStream, Name, DL); + } + return MangledName; + } + + LogicalModuleResources* getLogicalModuleResourcesForSymbol(const std::string &Name, bool ExportedSymbolsOnly) { + for (auto LMI = LogicalModules.begin(), LME = LogicalModules.end(); + LMI != LME; ++LMI) + if...

...you > are > >>> > lucky. A leading \1 is LLVM's way of saying: leave this name alone! > >>> > >>> Seems like I'm out of luck - the @<n> suffix is added > >>> (AddFastCallStdCallSuffix) in the GlobalValue > >>> Magnler::getNameWithPrefix overload, without paying respect to whether > >>> the name originally had a '\1' prefix or not. > >>> > >>> Should this be changed? > >>> > >>> David > >>> _______________________________________________ > >>&g...

...e orc { > @@ -77,6 +79,24 @@ public: > return LMH->Resources; > } > > + static std::string mangle(StringRef Name, const DataLayout &DL) { > + std::string MangledName; > + { > + raw_string_ostream MangledNameStream(MangledName); > + Mangler::getNameWithPrefix(MangledNameStream, Name, DL); > + } > + return MangledName; > + } > + > + LogicalModuleResources* getLogicalModuleResourcesForSymbol(const > std::string &Name, bool ExportedSymbolsOnly) { > + for (auto LMI = LogicalModules.begin(), LME = LogicalModules.end(); &gt...

...public: >> return LMH->Resources; >> } >> >> + static std::string mangle(StringRef Name, const DataLayout &DL) { >> + std::string MangledName; >> + { >> + raw_string_ostream MangledNameStream(MangledName); >> + Mangler::getNameWithPrefix(MangledNameStream, Name, DL); >> + } >> + return MangledName; >> + } >> + >> + LogicalModuleResources* getLogicalModuleResourcesForSymbol(const >> std::string &Name, bool ExportedSymbolsOnly) { >> + for (auto LMI = LogicalModules.begin(), LME...

...LMH->Resources; >>> } >>> >>> + static std::string mangle(StringRef Name, const DataLayout &DL) { >>> + std::string MangledName; >>> + { >>> + raw_string_ostream MangledNameStream(MangledName); >>> + Mangler::getNameWithPrefix(MangledNameStream, Name, DL); >>> + } >>> + return MangledName; >>> + } >>> + >>> + LogicalModuleResources* getLogicalModuleResourcesForSymbol(const >>> std::string &Name, bool ExportedSymbolsOnly) { >>> + for (auto LMI =...

...>> } >>>> >>>> + static std::string mangle(StringRef Name, const DataLayout &DL) { >>>> + std::string MangledName; >>>> + { >>>> + raw_string_ostream MangledNameStream(MangledName); >>>> + Mangler::getNameWithPrefix(MangledNameStream, Name, DL); >>>> + } >>>> + return MangledName; >>>> + } >>>> + >>>> + LogicalModuleResources* getLogicalModuleResourcesForSymbol(const >>>> std::string &Name, bool ExportedSymbolsOnly) { >>&...

...have this division? Wouldn't it be better for the IL to have the '_': define i32 @_f() {.... This causes problems with LTO because the symbols seem by the first pass are not the same as the ones seen once the final .o is produced. It can be fixed by having libLTO call void Mangler::getNameWithPrefix, but I was wondering if it wouldn't be better the avoid mangling in LLVM completely. Cheers, Rafael

> While testing a File I/O sample program, I've encountered a link failure due > to missing implementation of "\01__isoc99_fscanf" function. I think this > function should be named "__isoc99_fscanf" instead. Please see the program > code and LLVM IR generated by DragonEgg and clang below. It shows that clang > generates "__isoc99_fscanf", while

...ngling if you are >>>> > lucky. A leading \1 is LLVM's way of saying: leave this name alone! >>>> >>>> Seems like I'm out of luck - the @<n> suffix is added >>>> (AddFastCallStdCallSuffix) in the GlobalValue >>>> Magnler::getNameWithPrefix overload, without paying respect to whether >>>> the name originally had a '\1' prefix or not. >>>> >>>> Should this be changed? >>>> >>>> David >>>> _______________________________________________ >>>> LLVM...

I am programmatically building some functions in intermediate representation, and trying to verify them, but the verifier always reports that there is a problem, and I can't see why. Minimal test case: #ifdef _MSC_VER #pragma warning(disable : 4141) #pragma warning(disable : 4530) #pragma warning(disable : 4624) #endif #include <llvm/IR/IRBuilder.h> #include <llvm/IR/Verifier.h>

...he set to the JIT with the resolver we created above and a newly// created SectionMemoryManager.returncantFail(CompileLayer.addModule(std::move(M),std::move(Resolver)));}JITSymbolfindSymbol(conststd::string Name){std::string MangledName;raw_string_ostream MangledNameStream(MangledName);Mangler::getNameWithPrefix(MangledNameStream,Name,DL);returnCompileLayer.findSymbol(MangledNameStream.str(),true);}voidremoveModule(ModuleHandleH){cantFail(CompileLayer.removeModule(H));}};}}| The code is 1-to-1 copied from LLVM web site,LLVM ORC JIT Example <https://llvm.org/docs/tutorial/BuildingAJIT3.html>. Could...

...ModuleSet(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); return CompileLayer.findSymbol(MangledNameStream.str(), true); } void removeModule(ModuleHandle H) { CompileLayer.removeModuleSet(H); } }; const std::string FUNC_NAME = "someFunction"; void runTest() { llvm::LLVMContext cont...

...>(), >> std::move(Resolver)); >> } >> >> JITSymbol findSymbol(const std::string Name) { >> std::string MangledName; >> raw_string_ostream MangledNameStream(MangledName); >> Mangler::getNameWithPrefix(MangledNameStream, Name, DL); >> return CompileLayer.findSymbol(MangledNameStream.str(), true); >> } >> >> void removeModule(ModuleHandle H) { >> CompileLayer.removeModuleSet(H); >> } >> }; >> >> const std::string FUN...

...std::move(Resolver)); >>>> } >>>> >>>> JITSymbol findSymbol(const std::string Name) { >>>> std::string MangledName; >>>> raw_string_ostream MangledNameStream(MangledName); >>>> Mangler::getNameWithPrefix(MangledNameStream, Name, DL); >>>> return CompileLayer.findSymbol(MangledNameStream.str(), true); >>>> } >>>> >>>> void removeModule(ModuleHandle H) { >>>> CompileLayer.removeModuleSet(H); >>>> } &gt...

Hi, I think ExecutionEngine as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. Personally, I'm using MCJIT and