search for: takeerror

...e; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); } if (auto Sym = findSymbol(MangledName, CheckFunctionsOnly)) { if (auto AddrOrErr = Sym.getAddress()) return *AddrOrErr; else { report_fatal_error(AddrOrErr.takeError()); } } else { report_fatal_error(Sym.takeError()); }}* If the function findSymbol return nullptr, we are executing report_fatal_error and kill everything :( What is the reason for this change? Is this a bug? If this is intended, how can we check from the ExecutionEngine that the symbol alre...

...g. Here is an example how to use the library by extracting and printing the objc class names: ``` MachOMetadata ObjCInfo(InputObject); if (auto ObjCClasses = ObjCInfo.classes()) { for (auto c : *ObjCClasses) { auto ObjCClass = *c; if (!ObjCClass) { handleError(ObjCClass.takeError()); continue; } auto name = ObjCClass->getName(); if (!name) { handleError(name.takeError()); continue; } outs() << *name << "\n"; } ``` I am preparing a patch and will send out when it is ready. Let me know if you ha...

...ut); if(error_code ec = mb.getError()) { errs() << ec.message(); return 1; } Expected<unique_ptr<Module>> m = parseBitcodeFile(mb->get()->getMemBufferRef(),context); if(error_code ec= errorToErrorCode(m.takeError()) ) { PassManager<Module> PM; DataLayout td("e-p:32:32:32" "-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64" "-f32:32:32-f64:64:64"); PM.add(new DataLayout(td)); return 0; } -----------------...

...gt; errs() << ec.message(); >> return 1; >> } >> >> Expected<unique_ptr<Module>> m = >> parseBitcodeFile(mb->get()->getMemBufferRef(),context); >> if(error_code ec= errorToErrorCode(m.takeError()) ) >> { >> PassManager<Module> PM; >> DataLayout td("e-p:32:32:32" >> "-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64" >> "-f32:32:32-f64:64:64"); >> PM.add(new...

...The first is easily implemented using an idiom I've seen in llvm-objdump and elsewhere: void check(TypedError Err) { if (!Err) return; logAllUnhandledErrors(std::move(Err), errs(), "<tool name>"); exit(1); } ... TypedErrorOr<Result> R = doSomething(); check(R.takeError()); ... *R; Side-note: you can actually go one better and replace this idiom with: template <typename T> T check(TypedErrorOr<T> ValOrErr) { if (!ValOrErr) { logAllUnhandledErrors(ValOrErr.takeError(), errs(), "<tool name>"); exit(1); } return std::move(*...

...to be > added to the responsibility set: > > if (JITSymbol Sym = FindSymbol(*S)) { > if (!Sym.getFlags().isStrong()) > Result.insert(S); // > <- _ZNSt6vectorIfSaIfEE17_M_default_appendEm should be added here. > } else if (auto Err = Sym.takeError()) > return std::move(Err); > > Is that not happening? > > Cheers, > Lang. > > > On Mon, Sep 16, 2019 at 9:36 AM Geoff Levner <glevner at gmail.com> wrote: > >> I have found the cause of our problems with implicit template >> instantiation, and...

...lo, I have the following snippet of code that causes valgrind to freak out over unitialized bytes. llvm::Expected<llvm::object::OwningBinary<llvm::object::ObjectFile>> e = llvm::object::ObjectFile::createObjectFile(llvm::StringRef(fname)); if (!e) { llvm::handleAllErrors(e.takeError(), [](const llvm::ErrorInfo<llvm::ECError> &EI) { std::cerr << EI.message() << std::endl; }); return 1; } Am I doing something wrong here? -- Will Song

...s have been assigned an address. So if your process is generating a set of symbols that may need to be transmitted to other sessions then you would write something like: auto Syms = ES.lookup(SearchOrder, SymbolsToTransmit, LookupKind::Static, SymbolState::Resolved); if (!Syms) reportError(Syms.takeError()); sendSymbolsToRemote(*Syms); Out of interest -- Is it necessary for your JIT itself to be split across two or more processes? I had always anticipated having a single ExecutionSession attached to the target process and then running just the compilers on other processes. That gives you a star-li...

Hi all, I am new to LLVM and have been working through the Kaleidoscope tutorial. Everything is working fine so far except for local externs (as opposed to things like the math functions, which are working). Note that I have seen this bug with the reference code listing, as well as my own code. link to code: https://llvm.org/docs/tutorial/LangImpl05.html#full-code-listing [c34n10 kaleidoscope]

...t; + std::vector<LLVMPerfJitDebugEntry> LineInfo; > + std::string SourceFileName; > + > + Expected<SymbolRef::Type> SymTypeOrErr = Sym.getType(); > + if (!SymTypeOrErr) { > + // TODO: Actually report errors helpfully. > + consumeError(SymTypeOrErr.takeError()); > + continue; > + } > + SymbolRef::Type SymType = *SymTypeOrErr; > + if (SymType != SymbolRef::ST_Function) > + continue; > + > + Expected<StringRef> Name = Sym.getName(); > + if (!Name) { > + // TODO: Actually report errors helpful...

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that

I have found the cause of our problems with implicit template instantiation, and it looks to me like a bug in Orc JIT in LLVM 8. (Perhaps Lang could confirm?) We use createLegacyLookupResolver() to create our symbol resolver, passing it a lookup function. Amongst other things, our function calls LegacyRTDyldObjectLinkingLayer::findSymbol() to look up symbols in the JIT. When a module is

...calculateHash(name); printf(">>>%s @ 0x%p\n", name.data(), element.second.getAddress()); this->symbolsOfInterrest[hash].adr = element.second.getAddress(); } } else { ES.reportError(result.takeError()); } this->mtx.unlock(); return (this->undefinedReferences.size() == 0ull); } I also attached a reporter to the ES which will handle “llvm::orc::SymbolsNotFound” by copying SymbolVector to the “undefinedReferences”. If I call this function and have every symbol resolve...

...e lib/Object has no diagnostic handler. > > > Side-note: you can actually go one better and replace this idiom with: > > > > template <typename T> > > T check(TypedErrorOr<T> ValOrErr) { > > if (!ValOrErr) { > > logAllUnhandledErrors(ValOrErr.takeError(), errs(), "<tool name>"); > > exit(1); > > } > > return std::move(*ValOrErr); > > } > > Yes, we do pretty much that in ELF/COFF lld. > > > > Using TypedError as a wrapper for std::error_code would prevent errors > from > >...

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

...just an alias. MR.notifyEmitted(); // And you're done. } else { // If we get here then the "test" symbol couldn't be resolved for some // reason, so we need to report that error and notify everyone that // "Planschi_test" failed too. ES.reportError(TestSym.takeError()); MR.failMaterialization(); } The code above takes care of the case where the Planschi module can be found. The other possibility is that you get to the end of your process that causes modules to "pop up" (whatever this is) and there's still no Planschi module. In this case you j...

On Tue, Apr 4, 2017 at 12:36 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > On 2017-Apr-04, at 12:12, Peter Collingbourne <peter at pcc.me.uk> wrote: > > On Mon, Apr 3, 2017 at 8:13 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Apr 3, 2017, at 7:08 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: >>

...calculateHash(name); printf(">>>%s @ 0x%p\n", name.data(), element.second.getAddress()); this->symbolsOfInterrest[hash].adr = element.second.getAddress(); } } else { ES.reportError(result.takeError()); } this->mtx.unlock(); return (this->undefinedReferences.size() == 0ull); } I also attached a reporter to the ES which will handle “llvm::orc::SymbolsNotFound” by copying SymbolVector to the “undefinedReferences”. If I call this function and have every symbol resolve...

Currently a power failure or other hard crash can cause lld leave a temporary file around. The same is true for other llvm tools. As an example, put a breakpoint in Writer.cpp:236 ("writeBuildId()") and restart the run a few times. You will get t.tmp43a735a t.tmp4deeabb t.tmp9bacdd3 t.tmpe4115c4 t.tmpeb01fff The same would happen if there was a fatal error between the