search for: getbinary

...st the following patch? Geoff --- RTDyldObjectLinkingLayer.h (revision 342448) +++ RTDyldObjectLinkingLayer.h (working copy) @@ -175,7 +175,7 @@ } ~ConcreteLinkedObject() override { - if (this->Parent.NotifyFreed) + if (this->Parent.NotifyFreed && ObjForNotify.getBinary()) this->Parent.NotifyFreed(K, *ObjForNotify.getBinary()); MemMgr->deregisterEHFrames();

https://bugs.freedesktop.org/show_bug.cgi?id=70510 Priority: medium Bug ID: 70510 Assignee: nouveau at lists.freedesktop.org Summary: Xorg crash on KDE init QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: estellnb at elstel.org Hardware: Other

...on have the right size). Sadly, This is my code (at the end of the main function into driver.cpp) : #### ErrorOr<OwningBinary<Binary>> BinaryOrErr = createBinary(file); if (std::error_code ec = BinaryOrErr.getError()) { return ec.value(); } Binary &Binary = *BinaryOrErr.get().getBinary(); object::ObjectFile *objfile; objfile = dyn_cast<ObjectFile>(&Binary); for (const SymbolRef &Symbol : objfile->symbols()) { uint64_t size; Symbol.getAddress(size); } #### During my previous search, I check machODump.cpp in order to see of the list all the function. They n...

I''m developing a site that will need to display images that will be stored in a location outside the site. What would be the easiest way to do this? The site will be running on a linux machine. Thanks, Will --------------------------------- You snooze, you lose. Get messages ASAP with AutoCheck in the all-new Yahoo! Mail Beta.

...{ >     SmallVector<char, 256> UniqueObjFileName; >     sys::fs::createUniqueFile("jit-object-%%%.o", UniqueObjFileName); >     std::error_code EC; >     raw_fd_ostream ObjFileStream(UniqueObjFileName.data(), EC, > sys::fs::F_RW); >     ObjFileStream.write(Obj->getBinary()->getData().data(),           >                                                                       >                                                                       >                                                                       >                                    ...

...RTDyldObjectLinkingLayer::ObjectPtr &Obj,                     const LoadedObjectInfo &Info) const {       M.UnfinalizedSections[H] = std::move(M.SectionsAllocatedSinceLastLoad);       M.SectionsAllocatedSinceLastLoad = SectionAddrSet();       M.MemMgr->notifyObjectLoaded(&M, *Obj->getBinary());     } OrcLazyJIT in lli on the other hand doesn't make use of the notification.It can however be reproducedthere too: diff --git a/tools/lli/OrcLazyJIT.h b/tools/lli/OrcLazyJIT.h index 47a2acc4d7e..41a7c99413b 100644 --- a/tools/lli/OrcLazyJIT.h +++ b/tools/lli/OrcLazyJIT.h @@ -62,7 +62,1...

Dear LLVM-Developers and Vinod Grover, we are trying to extend the cling C++ interpreter (https://github.com/root-project/cling) with CUDA functionality for Nvidia GPUs. I already developed a prototype based on OrcJIT and am seeking for feedback. I am currently a stuck with a runtime issue, on which my interpreter prototype fails to execute kernels with a CUDA runtime error. === How to use the

...er); ArgcDie.addAttribute(DW_AT_name, DW_FORM_strp, "argc"); //ArgcDie.addAttribute(DW_AT_type, DW_FORM_ref_addr, IntDie); // Crashes here... DG.generate(); auto Obj = object::ObjectFile::createObjectFile(Path); if (Obj) { DWARFContextInMemory DwarfContext(*Obj.get().getBinary()); uint32_t NumCUs = DwarfContext.getNumCompileUnits(); for (uint32_t i=0; i<NumCUs; ++i) { DWARFCompileUnit *U = DwarfContext.getCompileUnitAtIndex(i); if (U) U->getUnitDIE(false)->dump(llvm::outs(), U, -1u); } } But things fall down if I try to...

Hi Christian Your use case seems to have similar requirements as remote JITing in ORC. So far I haven't used that part myself and I am sure Lang can tell you much more about it. However, this comment on the RemoteObjectClientLayer class sounds promising for your questions (1) and (2): /// Sending relocatable objects to the server (rather than fully relocated /// bits) allows JIT'd code

...name, DW_FORM_strp, "argc"); > //ArgcDie.addAttribute(DW_AT_type, DW_FORM_ref_addr, IntDie); // Crashes here... > > DG.generate(); > > auto Obj = object::ObjectFile::createObjectFile(Path); > if (Obj) { > DWARFContextInMemory DwarfContext(*Obj.get().getBinary()); > uint32_t NumCUs = DwarfContext.getNumCompileUnits(); > for (uint32_t i=0; i<NumCUs; ++i) { > DWARFCompileUnit *U = DwarfContext.getCompileUnitAtIndex(i); > if (U) > U->getUnitDIE(false)->dump(llvm::outs(), U, -1u); > } > }...

...Die.addAttribute(DW_AT_type, DW_FORM_ref_addr, IntDie); // >> Crashes here... >>> >>> DG.generate(); >>> >>> auto Obj = object::ObjectFile::createObjectFile(Path); >>> if (Obj) { >>> DWARFContextInMemory DwarfContext(*Obj.get().getBinary()); >>> uint32_t NumCUs = DwarfContext.getNumCompileUnits(); >>> for (uint32_t i=0; i<NumCUs; ++i) { >>> DWARFCompileUnit *U = DwarfContext.getCompileUnitAtIndex(i); >>> if (U) >>> U->getUnitDIE(false)->dump(llvm::out...

...ORM_ref_addr, IntDie); // > >> Crashes here... > >>> > >>> DG.generate(); > >>> > >>> auto Obj = object::ObjectFile::createObjectFile(Path); > >>> if (Obj) { > >>> DWARFContextInMemory DwarfContext(*Obj.get().getBinary()); > >>> uint32_t NumCUs = DwarfContext.getNumCompileUnits(); > >>> for (uint32_t i=0; i<NumCUs; ++i) { > >>> DWARFCompileUnit *U = DwarfContext.getCompileUnitAtIndex(i); > >>> if (U) > >>> U->getUnitDIE(...

...> + const ObjectFile &Obj, > + const RuntimeDyld::LoadedObjectInfo &L) { > + > + if (!SuccessfullyInitialized) > + return; > + > + OwningBinary<ObjectFile> DebugObjOwner = L.getObjectForDebug(Obj); > + const ObjectFile &DebugObj = *DebugObjOwner.getBinary(); > + > + // Get the address of the object image for use as a unique identifier > + DWARFContextInMemory Context(DebugObj); > + > + // Use symbol info to iterate functions in the object. > + for (const std::pair<SymbolRef, uint64_t> &P : computeSymbolSizes(DebugObj)...

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