search for: finalizeload

Displaying 4 results from an estimated 4 matches for "finalizeload".

2016 Oct 07
3
RuntimeDyLdCOFF and RTTI on Windows
...ject files with RuntimeDyLd. <snip> Do you think it is possible that RuntimeDyLd misses type info data in > the COFF file or doesn't wire it up correctly? > I set ProcessAllSections = true, but I didn't recognize any change. I > found that RuntimeDyLdCOFF does not override finalizeLoad like the ELF > and MachO versions. The function call's comment reads "Give the > subclasses a chance to tie-up any loose ends" -- possibly missing > functionality? > Unfortunately I don't have a windows machine to test on, so it's difficult to know for sure. From...
2015 Jan 26
2
[LLVMdev] [llvm] r188726 - Adding PIC support for ELF on x86_64 platforms
...--- llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp (original) +++ llvm/trunk/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp Mon Aug 19 18:27:43 2013 @@ -169,6 +169,9 @@ ObjectImage *RuntimeDyldImpl::loadObject } } + // Give the subclasses a chance to tie-up any loose ends. + finalizeLoad(); + return obj.take(); } @@ -424,6 +427,10 @@ uint8_t *RuntimeDyldImpl::createStubFunc writeInt16BE(Addr+6, 0x07F1); // brc 15,%r1 // 8-byte address stored at Addr + 8 return Addr; + } else if (Arch == Triple::x86_64) { + *Addr = 0xFF; // jmp + *(Addr+1) = 0x2...
2016 Oct 24
2
RuntimeDyLdCOFF and RTTI on Windows
...t; >> >> Do you think it is possible that RuntimeDyLd misses type info data in >>> the COFF file or doesn't wire it up correctly? >>> I set ProcessAllSections = true, but I didn't recognize any change. I >>> found that RuntimeDyLdCOFF does not override finalizeLoad like the ELF >>> and MachO versions. The function call's comment reads "Give the >>> subclasses a chance to tie-up any loose ends" -- possibly missing >>> functionality? >>> >> >> Unfortunately I don't have a windows machine to test...
2015 Jan 18
3
[LLVMdev] [MCJIT] Multiple GOT handling in RuntimeDyldELF
Hello everyone, As part of my quest to add TLS relocation support to MCJIT, I've been taking a closer look at the GOT implementation in RuntimeDyldELF and I believe that is not valid as currently implemented. In particular, I am wondering about the multiple GOT handling support introduced in r192020. If I understand correctly this can make code reuse the GOT table entry in a different object