search for: processrelocationref

...s like RuntimeDyldCOFFX86_64.h or RuntimeDyldCOFFI386.h etc, what is the connection of these files for relocation and linking as the linking and relocation for diff architecture is done in RuntimeDyldELF.cpp, RuntimeDyldCOFF.cpp and it doesn't use any function from these header file except the processRelocationRef(). The header files in Targets/ also handles exceptions, so what is the need for that in relocation and linking process ? Also please help with what this processRelocationRef() actually does ? . Please guide. sincerely, Siddharth -------------- next part -------------- An HTML attachment was scrub...

Thanks for the reply. I was just asking about in general whatever header files are there in Targets/ for different architectures are not including any function except this processRelocationRef() to be used in RuntimeDyldELF.cpp or RuntimeDyldCOFF.cpp or RuntimeDyldMachO.cpp and i think these files are the ones which are actually doing the relocation and linking work. So what purpose do these header files inside Targets/ actually serve. Also they include exception handling in form of exce...

Thanks for reply, it was really helpful. Can u just be more specific and tell about processRelocationRef() and resolveRelocation() in Targets/RuntimeDyld(objectfile format)(arch).h and also in RuntimeDyldELF.cpp and how the same function is implemented in different ways in both the files ? Thanks, Siddharth On Thu, Apr 20, 2017 at 8:16 PM, mats petersson <mats at planetcatfish.com> wrote: >...

...e, but specific questions will get more attention. > > -- > Mats > > On 21 April 2017 at 14:54, Siddharth Shankar Swain < > h2015096 at pilani.bits-pilani.ac.in> wrote: > >> Thanks for reply, it was really helpful. Can u just be more specific and >> tell about processRelocationRef() and resolveRelocation() in >> Targets/RuntimeDyld(objectfile format)(arch).h and also in >> RuntimeDyldELF.cpp and how the same function is implemented in different >> ways in both the files ? >> Thanks, >> Siddharth >> >> On Thu, Apr 20, 2017 at 8:16 PM,...

...the cantFail is failing. As to why that flag is set, I'm at a loss. I have run through GDB with both the sin and putchard examples, to try and see where they are diverging. I'm not totally sure, but I think the divergence might be happening on line 347 of RuntimeDyld.cpp: if (auto IOrErr = processRelocationRef(SectionID, I, Obj, LocalSections, Stubs)) That is, in the sin example, this expression is false; in the putchard example, it is true. However there may be something earlier on that I missed – there were a few thousand lines of GDB logging to diff through. It appears not to be an issue with the fu...

...oks like RecordingMemoryManager in lli just calls malloc() and it would be strange to make assumptions (or enforce) that the difference between two returned pointers in 64-bit virtual address space will be fit into 32 bits. Can we do smth similar to what Adhemerval proposed (see the special case in processRelocationRef for ELF::R_PPC64_REL24 relocations)? On Tue, Jan 29, 2013 at 9:40 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Hi Alexey,**** > > ** ** > > I think the most likely way to resolve this is to have the > RecordingMemoryManager do something more complex to manage...

...er in lli just calls malloc() and it would > be strange to make assumptions (or enforce) that the difference between two > returned pointers in 64-bit**** > > virtual address space will be fit into 32 bits. Can we do smth similar to > what Adhemerval proposed (see the special case in processRelocationRef for > ELF::R_PPC64_REL24 relocations)?**** > > ** ** > > On Tue, Jan 29, 2013 at 9:40 PM, Kaylor, Andrew <andrew.kaylor at intel.com> > wrote:**** > > Hi Alexey,**** > > **** > > I think the most likely way to resolve this is to have the > RecordingMemo...

...oks like RecordingMemoryManager in lli just calls malloc() and it would be strange to make assumptions (or enforce) that the difference between two returned pointers in 64-bit virtual address space will be fit into 32 bits. Can we do smth similar to what Adhemerval proposed (see the special case in processRelocationRef for ELF::R_PPC64_REL24 relocations)? On Tue, Jan 29, 2013 at 9:40 PM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote: Hi Alexey, I think the most likely way to resolve this is to have the RecordingMemoryManager do something more complex to manage...

...oks like RecordingMemoryManager in lli just calls malloc() and it would be strange to make assumptions (or enforce) that the difference between two returned pointers in 64-bit virtual address space will be fit into 32 bits. Can we do smth similar to what Adhemerval proposed (see the special case in processRelocationRef for ELF::R_PPC64_REL24 relocations)? On Tue, Jan 29, 2013 at 9:40 PM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote: Hi Alexey, I think the most likely way to resolve this is to have the RecordingMemoryManager do something more complex to manage...

Hi! I'm trying to run LLVM test suite under AddressSanitizer and get test failures in: LLVM :: ExecutionEngine/MCJIT/simpletest-remote.ll LLVM :: ExecutionEngine/MCJIT/test-data-align-remote.ll LLVM :: ExecutionEngine/MCJIT/test-fp-no-external-funcs-remote.ll LLVM :: ExecutionEngine/MCJIT/test-global-init-nonzero-remote.ll All of them fail with assertion: lli:

...e required memory but it did not trigger more crashes.I debugged through the allocation code including the Win32 code and it seems to work well. I have also tried disabling the MemGroup.FreeMem cache which did not matter. An added assert for no Stubs to the end of RuntimeDyldImpl::loadObject processRelocationRef(SectionID, *i, *obj, LocalSections, LocalSymbols, Stubs); assert(!Stubs.size()); indeed caught nothing = no stubs created. Disabling (de)registerEH did not help. Looking at relocations and sections printouts, the exception is: Unhandled exception at 0x0A3600D1 : 0xC0000005: Access viola...

...tion + // based on the load/target address of the GOT (not the current/local addr). + uint64_t GOTAddr = findGOTEntry(Value, SymOffset); + uint32_t *Target = reinterpret_cast<uint32_t*>(Section.Address + Offset); + uint64_t FinalAddress = Section.LoadAddress + Offset; + // The processRelocationRef method combines the symbol offset and the addend + // and in most cases that's what we want. For this relocation type, we need + // the raw addend, so we subtract the symbol offset to get it. + int64_t RealOffset = GOTAddr + Addend - SymOffset - FinalAddress; + assert(RealOffset &l...

...e required memory but it did not trigger more crashes.I debugged through the allocation code including the Win32 code and it seems to work well. I have also tried disabling the MemGroup.FreeMem cache which did not matter. An added assert for no Stubs to the end of RuntimeDyldImpl::loadObject processRelocationRef(SectionID, *i, *obj, LocalSections, LocalSymbols, Stubs); assert(!Stubs.size()); indeed caught nothing = no stubs created. Disabling (de)registerEH did not help. Looking at relocations and sections printouts, the exception is: Unhandled exception at 0x0A3600D1 : 0xC0000005:...

....I debugged through the > allocation code including the Win32 code and it seems to work well. I have > also tried disabling the MemGroup.FreeMem cache which did not matter.**** > > ** ** > > An added assert for no Stubs to the end of RuntimeDyldImpl::loadObject**** > > processRelocationRef(SectionID, *i, *obj, LocalSections, > LocalSymbols,**** > > Stubs);**** > > assert(!Stubs.size());**** > > indeed caught nothing = no stubs created.**** > > ** ** > > Disabling (de)registerEH did not help.**** > > ** ** > > Looking...

Hi Ulrich, and any other llvm PowerPC/JIT users, It looks like the Numba maintainers have run in to an issue with RuntimeDyldELF's PowerPC support (See https://github.com/numba/numba/issues/2451#issuecomment-377739948 and later comments) Due to a recent change to weak symbol handling, we now always resolve to the first copy of a function that is emitted (discarding redundant weak/odr

...n code including the Win32 code and it seems to work well. I have >> also tried disabling the MemGroup.FreeMem cache which did not matter.**** >> >> ** ** >> >> An added assert for no Stubs to the end of RuntimeDyldImpl::loadObject*** >> * >> >> processRelocationRef(SectionID, *i, *obj, LocalSections, >> LocalSymbols,**** >> >> Stubs);**** >> >> assert(!Stubs.size());**** >> >> indeed caught nothing = no stubs created.**** >> >> ** ** >> >> Disabling (de)registerEH did not...

...n code including the Win32 code and it seems to work well. I have >> also tried disabling the MemGroup.FreeMem cache which did not matter.**** >> >> ** ** >> >> An added assert for no Stubs to the end of RuntimeDyldImpl::loadObject*** >> * >> >> processRelocationRef(SectionID, *i, *obj, LocalSections, >> LocalSymbols,**** >> >> Stubs);**** >> >> assert(!Stubs.size());**** >> >> indeed caught nothing = no stubs created.**** >> >> ** ** >> >> Disabling (de)registerEH did not...

Hi Alexey, I think the most likely way to resolve this is to have the RecordingMemoryManager do something more complex to manage its allocations in such a way as to guarantee that they are all within proximity of one another. The code that is asserting is handling a relocation where code was generated to use a 32-bit relative offset in 64-bit code. If the two sections involved really are more

...o work well. I have >>> also tried disabling the MemGroup.FreeMem cache which did not matter.*** >>> * >>> >>> ** ** >>> >>> An added assert for no Stubs to the end of RuntimeDyldImpl::loadObject** >>> ** >>> >>> processRelocationRef(SectionID, *i, *obj, LocalSections, >>> LocalSymbols,**** >>> >>> Stubs);**** >>> >>> assert(!Stubs.size());**** >>> >>> indeed caught nothing = no stubs created.**** >>> >>> ** ** >>> &g...

...o work well. I have >>> also tried disabling the MemGroup.FreeMem cache which did not matter.*** >>> * >>> >>> ** ** >>> >>> An added assert for no Stubs to the end of RuntimeDyldImpl::loadObject** >>> ** >>> >>> processRelocationRef(SectionID, *i, *obj, LocalSections, >>> LocalSymbols,**** >>> >>> Stubs);**** >>> >>> assert(!Stubs.size());**** >>> >>> indeed caught nothing = no stubs created.**** >>> >>> ** ** >>> &g...