[LLVMdev] Support for Windows Phone 8.1
Saleem Abdulrasool
compnerd at compnerd.org
Mon Jun 23 23:35:34 PDT 2014
On Mon, Jun 23, 2014 at 2:22 AM, Damanjit Singh <dsingh at adobe.com> wrote:
> Hi Saleem thanks for fixing issue #1. Will verify and let you know soon
> how it works for me.
>
> For issue #2,
> I have placed an example ll, obj and it’s disassembled files at
> https://dl.dropboxusercontent.com/u/9953890/llvm/builtin_abc.ll,
> https://dl.dropboxusercontent.com/u/9953890/llvm/builtin_abc.obj ,
> https://dl.dropboxusercontent.com/u/9953890/llvm/builtin_abc.disasm and
> https://dl.dropboxusercontent.com/u/9953890/llvm/builtin_abc.disasm_all
> respectively.
>
> You may see that in the disasm file, in function
> builtin:473:global$init: , line 5565, *b.w* instruction is used. But in
> disarm_all file, the relocations used for this doesn’t have any entry for
> IMAGE_REL_ARM_BRANCH20T or IMAGE_REL_ARM_BRANCH24. Is that OK or an issue
> here?
>
> I don’t have a smaller example as yet. Let me know is this example works
> for you?
>
Hmm ... this is an instance of a known issue (constant island pass
corrupting the instruction stream). I do have a change that is ... of
questionable correctness ... which should help with the issue at:
http://reviews.llvm.org/D3265 The alternative would be to split up the
rather large single function into multiple functions.
This is certainly an issue that is on my list of things to address.
Thanks,
> Daman
>
> From: Saleem Abdulrasool <compnerd at compnerd.org>
> Date: Monday, 23 June 2014 6:49 am
> To: Damanjit Singh <dsingh at adobe.com>
> Cc: Saleem Abdulrasool <abdulras at fb.com>, Nick Lewycky <nicholas at mxc.ca>,
> "llvmdev at cs.uiuc.edu" <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] Support for Windows Phone 8.1
>
> On Wed, Jun 18, 2014 at 10:25 AM, Saleem Abdulrasool <
> compnerd at compnerd.org> wrote:
>
>> On Wed, Jun 18, 2014 at 9:09 AM, Damanjit Singh <dsingh at adobe.com>
>> wrote:
>>
>>> Hi Saleem,
>>>
>>> Though a simple app works great I am facing few issues trying to link
>>> a slightly complex object file, generated via LLVM, with some libs
>>> generated via Visual Studio -
>>> 1. Seems IMAGE_SCN_MEM_16BIT is only written for the the first header in
>>> the COFF file, thus functions in other headers (if you are using function
>>> sections) don’t work. I was able to workaround this by forcing this entry
>>> for each header by making some (hacky) changes in LLVM sources. I am not
>>> much familiar with the LLVM source code, thus would better let the experts
>>> to do a correct fix for this issue.
>>>
>>
>> Sounds like non-default text sections aren't being emitted correctly.
>> This would be problematic, particularly in the future if we are to
>> maintain compatibility with the Microsoft toolchain. They are switching to
>> grouped sections by default for aiding optimizations. I will look into
>> this.
>>
>
> -ffunction-sections should be addressed with SVN r211481. Thanks for
> letting us know about this issue.
>
>
>> 2. There is something strange happening with *b.w* instruction in the
>>> final linked executable. I see that in the disassembly for object code
>>> (generated via LLVM with thumbv7-windows-msvc triple), the b.w instruction
>>> correctly points to the label I want. But after linking, it now points to
>>> some random address. Seems like there are some fixup issues related to
>>> *b.w* instruction. Note that I am using Visual Studio’s linker to
>>> create a Window’s phone app.
>>>
>>
>> This is interesting. It sounds like this should be an
>> IMAGE_REL_ARM_BRANCH20T relocation. I've never really seen any issues with
>> this particular relocation. I would need some code that generates the
>> issue that you are seeing so that I can investigate the cause of the bad
>> linking (or at least something with which to reproduce the issue).
>>
>> It may be informative to determine what the difference is between the
>> emitted location and what it should be.
>>
>
> I am still waiting for some information on how to reproduce this.
>
>
>> I would really appreciate any help, or pointers for further
>>> investigation, for the second issue above.
>>>
>>> Thanks,
>>> Daman
>>>
>>> On 09/06/14 8:45 pm, "Saleem Abdulrasool" <abdulras at fb.com> wrote:
>>>
>>>
>>> On Jun 8, 2014, at 10:46 PM, Damanjit Singh <dsingh at adobe.com> wrote:
>>>
>>> Thanks a lot Saleem,
>>> The issue is fixed and a simple app works fine now.
>>>
>>>
>>> Awesome; thanks for the verification.
>>>
>>> -Daman
>>> On 08/06/14 12:57 pm, "Nick Lewycky" <nicholas at mxc.ca> wrote:
>>>
>>> Damanjit Singh wrote:
>>>
>>> Thanks Saleem, Nick.
>>> I will try with the latest code and share the results.
>>> Though, just curious if I need to really use clang to generate the
>>> object file and the current steps won't work? I ask because using .c
>>> file was only an illustration. For my project the IR is not generated
>>> from .c files or clang.
>>>
>>> You don't need to use clang. When you use clang you have to tell it
>>> what
>>> target it's targeting.
>>> If you're starting with IR, try "llc -filetype=obj foo.bc -o foo.obj
>>> -mtriple=..." to produce a .o file directly. I'm not experienced with it
>>> myself but I've heard that MSVC will produce assembly that it can't
>>> parse, so it's probably a good idea to leave assembly out of the
>>> equation when targeting Windows.
>>> Nick
>>>
>>> On 08-Jun-2014, at 11:00 am, "Saleem Abdulrasool" <compnerd at compnerd.org
>>> <mailto:compnerd at compnerd.org> <compnerd at compnerd.org%3E>> wrote:
>>>
>>> On Sat, Jun 7, 2014 at 4:49 PM, Nick Lewycky <nicholas at mxc.ca
>>> <mailto:nicholas at mxc.ca> <nicholas at mxc.ca%3E>> wrote:
>>> Damanjit Singh wrote:
>>> Hi guys,
>>> Would really appreciate any help here.
>>> Thanks,
>>> Daman
>>> From: Damanjit Singh <dsingh at adobe.com
>>> <mailto:dsingh at adobe.com <dsingh at adobe.com>> <
>>> mailto:dsingh at adobe.com>> <dsingh at adobe.com%3E%3E>> <
>>> mailto:dsingh at adobe.com>> <dsingh at adobe.com%3E%3E>>
>>> Date: Friday, 6 June 2014 12:57 pm
>>> To: "llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu
>>> <llvmdev at cs.uiuc.edu>>
>>> <mailto:llvmdev at cs.uiuc.edu%20%3Cmailto:llvmdev at cs.uiuc.edu>>
>>> <llvmdev at cs.uiuc.edu%20%3Cmailto:llvmdev at cs.uiuc.edu%3E%3E>"
>>> <llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu
>>> <llvmdev at cs.uiuc.edu>>
>>> <mailto:llvmdev at cs.uiuc.edu%20%3Cmailto:llvmdev at cs.uiuc.edu>>
>>> <llvmdev at cs.uiuc.edu%20%3Cmailto:llvmdev at cs.uiuc.edu%3E%3E>>
>>> Subject: Support for Windows Phone 8.1
>>> Hi LLVMdev,
>>> Does the latest trunk code support Windows Phone 8.1 target ?
>>> I don't know this, but ...
>>> I was trying out a simple program, but Visual Studio 2013¹s
>>> linker
>>> failed for me with this error - app.obj : error LNK2008: Fixup
>>> target is
>>> not aligned Œadd3'
>>> This is what I tried -
>>> * Download latest LLVM sources (as on 4th June) and build them
>>> on my
>>> MAC 10.9 machine.
>>> * Wrote a simple a.c, with add3 function-
>>> int add3(int i, int j)
>>> {
>>> int k = i+j;
>>> return k;
>>> }
>>> * Create LLVM IR using Xcode 5.1¹s clang ( *clang S -O0
>>> -emitllvm a.c* )
>>> * Create obj file using llc - *. /i686-apple-darwin11-llc
>>> -filetype=obj -mtriple=thumbv7-windows-msvc -O0 a.s *
>>> ... in general this doesn't work. The transformation from C to
>>> LLVM IR needs to know the target triple. Try "clang
>>> --target=thumbv7-windows-msvc a.c -c -o a.obj"? Since clang has a
>>> built-in assembler, you should get a valid COFF file out, to the
>>> extent that clang and llvm support this target.
>>> If that doesn't work, I may suggest it's unsupported.
>>> As Nick mentioned, please generate the object file directly from
>>> clang. You can use armv7-windows or thumbv7-windows (clang will
>>> translate armv7-windows to thumbv7-windows implicitly). I just fixed a
>>> bug that should allow you to link the object files with link.
>>> Nick
>>> * Now on a Windows 8.1 Desktop machine, link this object file
>>> into
>>> sample (new DirectX app, windows phone) Visual Studio 2013
>>> project.
>>> * Declare and Call add3 in the sample windows project.
>>> * I then get a linker error on building the solution.
>>> *1>app.obj : error LNK2008: Fixup target is not aligned 'add3'*
>>> *1>LINK : fatal error LNK1165: link failed because of fixup
>>> errors*
>>> *========== Rebuild All: 0 succeeded, 1 failed, 0 skipped
>>> ==========*
>>> Could someone please confirm about the state of support for
>>> Windows
>>> Phone 8.1 ? Or am I missing something here?
>>> Thanks,
>>> Daman
>>> ______________________________ _________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu
>>> <LLVMdev at cs.uiuc.edu>>
>>>
>>> https://urldefense.proofpoint.com/v1/url?u=http://llvm.cs.uiuc.edu/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=0Qe%2Bx9MyG7ElZcfL7G1YH5wesJKdCF6vcfoxdGGlllA%3D%0A&s=3b8b44359c57ff853178c7ac52020429ecdd7082f0022b9df52ceccce0c2c037
>>>
>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.cs.uiuc.edu/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=0Qe%2Bx9MyG7ElZcfL7G1YH5wesJKdCF6vcfoxdGGlllA%3D%0A&s=c2b3af446125b243021edc6166e06545c6537664f0739fcd73f556617e6a12a8
>>> mailman/listinfo/llvmdev
>>> <
>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=0Qe%2Bx9MyG7ElZcfL7G1YH5wesJKdCF6vcfoxdGGlllA%3D%0A&s=ccdee7a002753f1de3fb195d0b136caf547181d34ca78c2062b54f3c11c91b5f
>>> >
>>> ______________________________ _________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu
>>> <LLVMdev at cs.uiuc.edu>>
>>>
>>> https://urldefense.proofpoint.com/v1/url?u=http://llvm.cs.uiuc.edu/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=0Qe%2Bx9MyG7ElZcfL7G1YH5wesJKdCF6vcfoxdGGlllA%3D%0A&s=3b8b44359c57ff853178c7ac52020429ecdd7082f0022b9df52ceccce0c2c037
>>>
>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.cs.uiuc.edu/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=0Qe%2Bx9MyG7ElZcfL7G1YH5wesJKdCF6vcfoxdGGlllA%3D%0A&s=c2b3af446125b243021edc6166e06545c6537664f0739fcd73f556617e6a12a8
>>> mailman/listinfo/llvmdev
>>> <
>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=0Qe%2Bx9MyG7ElZcfL7G1YH5wesJKdCF6vcfoxdGGlllA%3D%0A&s=ccdee7a002753f1de3fb195d0b136caf547181d34ca78c2062b54f3c11c91b5f
>>> >
>>> --
>>> Saleem Abdulrasool
>>> compnerd (at) compnerd (dot) org
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu
>>> https://urldefense.proofpoint.com/v1/url?u=http://llvm.cs.uiuc.edu/&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=0Qe%2Bx9MyG7ElZcfL7G1YH5wesJKdCF6vcfoxdGGlllA%3D%0A&s=3b8b44359c57ff853178c7ac52020429ecdd7082f0022b9df52ceccce0c2c037
>>>
>>> https://urldefense.proofpoint.com/v1/url?u=http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev&k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0A&r=CchYc4lrV44%2BZqxZADw0BQ%3D%3D%0A&m=0Qe%2Bx9MyG7ElZcfL7G1YH5wesJKdCF6vcfoxdGGlllA%3D%0A&s=ccdee7a002753f1de3fb195d0b136caf547181d34ca78c2062b54f3c11c91b5f
>>>
>>>
>>> --
>>> Saleem Abdulrasool
>>> abdulras (at) fb (dot) com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Saleem Abdulrasool
>> compnerd (at) compnerd (dot) org
>>
>
>
>
> --
> Saleem Abdulrasool
> compnerd (at) compnerd (dot) org
>
--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140623/8df01913/attachment.html>
More information about the llvm-dev
mailing list