[LLVMdev] Remaining big-endian host issues in RuntimeDyld

Daniel Sanders
Tue, 04 Nov 2014 16:23:45 -0000

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>