search for: symbolstate

...lacement.h:23, from /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.cpp:9: /path/to/llvm/include/llvm/ExecutionEngine/Orc/Core.h:690:25: warning: 'llvm::orc::JITDylib::SymbolTableEntry::State' is too small to hold all values of 'enum class llvm::orc::JITDylib::SymbolState' SymbolState State : 6; There is no GCC option for disabling this warning: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 The issue is that now LLVM is not buildable with GCC and '-Werror' enabled. In addition, LLVM gcc-werror buildbot seems to be offline since May 9th: http:...

Hi Bjoern, Thanks for your patience. The good news is that there is a neater way to do this: ExecutionSession's lookup methods take a orc::SymbolState parameter which describes the state that symbols must reach before a query can return (See https://github.com/llvm/llvm-project/blob/d1a7bfca74365c6523e647fcedd84f8fa1972dd3/llvm/include/llvm/ExecutionEngine/Orc/Core.h#L1273).In your case you want to use orc::SymbolState::Resolved, which will cause...

...rom >> /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.cpp:9: >> >> /path/to/llvm/include/llvm/ExecutionEngine/Orc/Core.h:690:25: warning: >> ‘llvm::orc::JITDylib::SymbolTableEntry::State’ is too small to hold all >> values of ‘enum class llvm::orc::JITDylib::SymbolState’ >> >> SymbolState State : 6; >> >> >> >> There is no GCC option for disabling this warning: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 >> >> The issue is that now LLVM is not buildable with GCC and ‘-Werror’ >> enabled. &g...

...LookupSet lookupSet; lookupSet.add("?Sampler@@YAXXZ", llvm::orc::SymbolLookupFlags::WeaklyReferencedSymbol); ES.lookup({{&jit->getMainJITDylib(), llvm::orc::JITDylibLookupFlags::MatchAllSymbols}}, lookupSet, llvm::orc::LookupKind::Static, llvm::orc::SymbolState::Resolved); Even though the "tryToGenerate" function of my DefinitionGenerator returned a "llvm::orc::SymbolsNotFound" for the "?_Plansch_test@@3HA", I got an address for "?Sampler@@YAXXZ". Dumping the "MainJITDylib" I saw, that the "?Sampler@...

...ion::lookup(llvm::orc::LookupKind K, const std::vector<std::pair<llvm::orc::JITDylib *,enum llvm::orc::JITDylibLookupFlags>,std::allocator<std::pair<llvm::orc::JITDylib *,enum llvm::orc::JITDylibLookupFlags>>> & SearchOrder, llvm::orc::SymbolLookupSet Symbols, llvm::orc::SymbolState RequiredState, llvm::unique_function<void __cdecl(llvm::Expected<llvm::DenseMap<llvm::orc::SymbolStringPtr,llvm::JITEvaluatedSymbol,llvm::DenseMapInfo<llvm::orc::SymbolStringPtr>,llvm::detail::DenseMapPair<llvm::orc::SymbolStringPtr,llvm::JITEvaluatedSymbol>>>)> Notify...

...onSession.lookup? Hi Bjoern, Even though the "tryToGenerate" function of my DefinitionGenerator returned a "llvm::orc::SymbolsNotFound" for the "?_Plansch_test@@3HA", I got an address for "? That's because you're issuing the lookup with RequiredState == SymbolState::Resolved. This means that your query will return as soon as "?Sampler@@YAXXZ" is assigned an address. In the JIT linker(s) addresses are assigned before external references are looked up. So after your lookup returns the linker attempts to find "?_Plansch_test@@3HA", fails, and...

Hello LLVM-Mailing-List and Lang, I have a very weird (or strict?) scenario and was curious if the ORC JIT can help me with it. Soo here it comes: I have currently a windows process ("Runtime") which does nothing but creating a shared memory with read, write and execute rights - and also writing some function addresses like from printf to it. Then I have two or more processes which

Chris Lattner wrote: > > Second, MO_ExternalSymbol is used for storing name of external > > variable/function, right? Why it's not possible to use MO_GlobalAddress, > > where returned GlobalValue* has isExternal set to true? The > > GlobalValue::getName would return the name of the symbol. > > Using the GlobalValue is certainly the preferred way if you have it.

...onSession.lookup? Hi Bjoern, Even though the "tryToGenerate" function of my DefinitionGenerator returned a "llvm::orc::SymbolsNotFound" for the "?_Plansch_test@@3HA", I got an address for "? That's because you're issuing the lookup with RequiredState == SymbolState::Resolved. This means that your query will return as soon as "?Sampler@@YAXXZ" is assigned an address. In the JIT linker(s) addresses are assigned before external references are looked up. So after your lookup returns the linker attempts to find "?_Plansch_test@@3HA", fails, and...

On Fri, 18 Jun 2004, Vladimir Prus wrote: > > actually exist in the LLVM module for the function. In particular, this > > would include any functions in a code-generator specific runtime library > > and malloc/free. The X86 code generator compiles floating point modulus > > into fmod calls, and 64-bit integer div/rem into runtime library calls. > > And why isn't

...cutionSession::lookup(llvm::orc::LookupKind, std::__1::vector<std::__1::pair<llvm::orc::JITDylib*, llvm::orc::JITDylibLookupFlags>, std::__1::allocator<std::__1::pair<llvm::orc::JITDylib*, llvm::orc::JITDylibLookupFlags> > > const&, llvm::orc::SymbolLookupSet, llvm::orc::SymbolState, llvm::unique_function<void (llvm::Expected<llvm::DenseMap<llvm::orc::SymbolStringPtr, llvm::JITEvaluatedSymbol, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr>, llvm::detail::DenseMapPair<llvm::orc::SymbolStringPtr, llvm::JITEvaluatedSymbol> > >)>, std::__1::function&l...

On Thu, 17 Jun 2004, Vladimir Prus wrote: > > Hi, > here I am again with "why is this so" kind of a question. Among different > types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. > > For MO_GlobalAddress, we can get usefull information from the getGlobal() > method, which returns GlobalValue*. Wouldn'it it be better is >

...;A" or "B" to be ready will find that their query doesn't return until both symbols are fully-materialized and safe to access. (2) Update the JIT state using your MaterializationResponsibility object: if (auto TestSym = ES.lookup({&PlanschiJD}, ES.intern("test")), SymbolState::Resolved) { // Tell the JIT that the address of PlanschiTest is the same // as the address of "test" in the Planschi JITDylib. MR.notifyResolved({ { ES.intern("Planschi_test"), JITEvaluatedSymbol(TestSym.getAddress(), JITSymbolFlag...

Hi, here I am again with "why is this so" kind of a question. Among different types of MachineOperand there are MO_ExternalSymbol and MO_GlobalAddress. For MO_GlobalAddress, we can get usefull information from the getGlobal() method, which returns GlobalValue*. Wouldn'it it be better is MO_GlobalAddress be called MO_GlobalValue, for consistency? Second, MO_ExternalSymbol is used

...lvm::orc::JITDylib*, >>>>> llvm::orc::JITDylibLookupFlags>, >>>>> std::__1::allocator<std::__1::pair<llvm::orc::JITDylib*, >>>>> llvm::orc::JITDylibLookupFlags> > > const&, llvm::orc::SymbolLookupSet, >>>>> llvm::orc::SymbolState, llvm::unique_function<void >>>>> (llvm::Expected<llvm::DenseMap<llvm::orc::SymbolStringPtr, >>>>> llvm::JITEvaluatedSymbol, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr>, >>>>> llvm::detail::DenseMapPair<llvm::orc::SymbolStringPtr, &g...

...olsOfInterrest) { lookupSet.add(element.second.name,llvm::orc::SymbolLookupFlags::WeaklyReferencedSymbol); } auto result = ES.lookup({{&jit->getMainJITDylib(), llvm::orc::JITDylibLookupFlags::MatchAllSymbols}}, lookupSet, llvm::orc::LookupKind::Static, llvm::orc::SymbolState::Resolved); if(result) { for(const auto &element : *result) { const llvm::StringRef &name = (*element.first); const size_t hash = calculateHash(name); printf(">>>%s @...

...m::orc::LookupKind, > std::__1::vector<std::__1::pair<llvm::orc::JITDylib*, > llvm::orc::JITDylibLookupFlags>, > std::__1::allocator<std::__1::pair<llvm::orc::JITDylib*, > llvm::orc::JITDylibLookupFlags> > > const&, llvm::orc::SymbolLookupSet, > llvm::orc::SymbolState, llvm::unique_function<void > (llvm::Expected<llvm::DenseMap<llvm::orc::SymbolStringPtr, > llvm::JITEvaluatedSymbol, llvm::DenseMapInfo<llvm::orc::SymbolStringPtr>, > llvm::detail::DenseMapPair<llvm::orc::SymbolStringPtr, > llvm::JITEvaluatedSymbol> > >)>,...

Chris Lattner wrote: > > And why isn't it possible to just make those functions known to LLVM? > > After all, *I think*, if this function is to be called, it should be > > declared in assembler, and so you have to pass some information abou > > those function to the code printer. (Of course, it's possible to just > > directly print the declarations, but

...cc5198eee21f0dbabe6af0a3180-bedda45c2776595c390d63af4d6c24c16f889af2>,llvm::orc::SymbolLookupFlags::WeaklyReferencedSymbol); } auto result = ES.lookup({{&jit->getMainJITDylib(), llvm::orc::JITDylibLookupFlags::MatchAllSymbols}}, lookupSet, llvm::orc::LookupKind::Static, llvm::orc::SymbolState::Resolved); if(result) { for(const auto &element : *result) { const llvm::StringRef &name = (*element.first); const size_t hash = calculateHash(name); printf(">>>%s @...