[LLVMdev] Support for Windows Phone 8.1
Saleem Abdulrasool
compnerd at compnerd.org
Sun Jun 22 18:19:09 PDT 2014
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140622/bad5295a/attachment.html>
More information about the llvm-dev
mailing list