[LLVMdev] Remaining big-endian host issues in RuntimeDyld

[Daniel Sanders]

I've found it. Host-endianness isn't accounted for when emitting the instructions in the ARM, AArch64, and Mips paths of RuntimeDyldImpl::createStubFunction(). I'll submit a patch for this soon. I'm not sure if PowerPC is affected or not. It uses big-endian order for ppc64_le which sounds odd but it also specifies the byte order which suggests it could be correct.

Also, I noticed that the AArch64 path is the only one that returns a pointer to the end of the stub function rather than the start. Is that correct?

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Daniel Sanders
Sent: 04 November 2014 15:47
To: lhames at gmail.com
Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
Subject: [LLVMdev] Remaining big-endian host issues in RuntimeDyld

Hi Lang,

Thanks for your help at the Hackers Lab. Fixing the problems we identified in RuntimeDyldMachOARM.h improves the MachO_ARM_PIC_relocations.s test quite a lot but there's one failed check that's proving a bit stubborn:
                Expression '*{4}(stub_addr(foo.o, __text, baz)) = 0xe51ff004' is false: 0x4f01fe5 != 0xe51ff004

I'm struggling to find the cause of this mismatch at the moment. Do you have any idea suggestions on where to look?

Daniel Sanders
Leading Software Design Engineer, MIPS Processor IP
Imagination Technologies Limited
www.imgtec.com<http://www.imgtec.com/>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/ad62e0b5/attachment.html>