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