[LLVMdev] Remaining big-endian host issues in RuntimeDyld

[Daniel Sanders]

David: There's one more patch after r221047. I've just submitted it to llvm-commits and you can find it at http://reviews.llvm.org/D6130. I haven't touched the PowerPC path of createStubFunction() in that patch since I'm not sure whether PowerPC's opcodes are endian-dependant and (unlike the other paths) it currently specifies an endianness.

Lang: Thanks for clarifying. I've left the AArch64 path returning the same value as it did before.

> -----Original Message-----
> From: David Fang [mailto:fang at csl.cornell.edu]
> Sent: 05 November 2014 00:37
> To: Lang Hames
> Cc: Daniel Sanders; LLVM Developers Mailing List (llvmdev at cs.uiuc.edu)
> Subject: Re: Remaining big-endian host issues in RuntimeDyld
> 
> Thanks, Lang and Daniel,
> 
> Are you referring to r221047? or other(s) yet to come?  My original bug
> report on potential endianness issues in RuntimeDyld for PPC is PR20640.
> I should have time later this week to merge-and-test trunk (my machine is
> busy bootstrapping 3.4 ...)
> 
> David
> 
> > Hi Daniel,
> >
> > Thanks very much - I really appreciate you tracking this down. David - once
> > Daniel's patch goes in it would be interesting to see what impact his work
> > has had on PPC. I expect this will fix some of the tests there too.
> >
> > Regarding the AArch64 stub-addr return: My read is that
> createStubFunction
> > returns a pointer to the start of the stub for AArch64. Those switch cases
> > are a bit inconsistent though: What address they return depends on what
> the
> > caller (relocation logic) wants to do to fix up the stub. That could be
> > modifying operands in the stub, or it could be tagging an extra absolute
> > address field after the stub. Hopefully we can start to clean this stuff up
> > as we move to a RuntimeDyld-class-per-target setup.
> >
> > Cheers,
> > Lang.
> >
> >
> > On Tue, Nov 4, 2014 at 8:23 AM, Daniel Sanders
> <Daniel.Sanders at imgtec.com>
> > wrote:
> >
> >>  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
> >>
> >>
> >>
> >
> 
> --
> David Fang
> http://www.csl.cornell.edu/~fang/