llvm dev - Nov 2014 - [LLVMdev] Remaining big-endian host issues in RuntimeDyld

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/d7cb419a/attachment.html>

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/

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/