[LLVMdev] Remaining big-endian host issues in RuntimeDyld

[David Fang]

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/