[LLVMdev] Support for Windows Phone 8.1

Wed Jun 25 21:33:23 PDT 2014

OK, I got something.

I am calling this function via a function pointer (and not a direct call). This function is not defined in this module but in another object file. How can I make a call via a function pointer and use “arm_aapcs_vfpcc” calling convention? I am already using setCallingConv(llvm::CallingConv::ARM_AAPCS_VFP) on the generated call instruction, but that doesn’t seem to cause any effect. Any ideas what I am missing here?

I will try to create a sample test case soon.

Thanks,
Daman

From: Damanjit Singh <dsingh at adobe.com<mailto:dsingh at adobe.com>>
Date: Thursday, 26 June 2014 8:59 am
To: Saleem Abdulrasool <compnerd at compnerd.org<mailto:compnerd at compnerd.org>>
Subject: Re: [LLVMdev] Support for Windows Phone 8.1

Thanks for the suggestion Saleem. It seems that the ll is missing the declaration of the external function being called. I guess I need to declare it correctly with “arm_aapcs_vfpcc” calling convention. Will let you know if that solves my problem.

Thanks again,
Daman

From: Saleem Abdulrasool <compnerd at compnerd.org<mailto:compnerd at compnerd.org>>
Date: Thursday, 26 June 2014 8:22 am
To: Damanjit Singh <dsingh at adobe.com<mailto:dsingh at adobe.com>>
Subject: Re: [LLVMdev] Support for Windows Phone 8.1

On Wed, Jun 25, 2014 at 3:33 AM, Damanjit Singh <dsingh at adobe.com<mailto:dsingh at adobe.com>> wrote:
Hi Saleem,

I am facing another issue. Does latest llvm support ARM_AAPCS_VFP calling convention, that is passing double/ float via VFP registers? The code produced using llc continues to use GPRs for passing double and float. My command line is of the form -  i686-apple-darwin11-llc -mtriple=thumbv7-windows-msvc -function-sections -data-sections -O0 -float-abi=hard -mattr=thumb2,vfp3,neon,d16 -filetype=obj a.ll.

Strangely, if I create a simple ll via Clang (just to multiply two numbers), and use the above command it works fine (that is, it  uses VPF registers for passing double values). But it does not work on my ll. Any ideas what could I be missing?

LLVM definitely supports AAPCS VFP.  I use clang and not llc (except for test cases which are engineered specifically to test details of the implementation).  How are you generating the ll input?  The content of the ll that reproduces the issue would be helpful in analyzing what is going wrong.

Thanks,
Daman

From: Saleem Abdulrasool <compnerd at compnerd.org<mailto:compnerd at compnerd.org>>
Date: Tuesday, 24 June 2014 12:05 pm

To: Damanjit Singh <dsingh at adobe.com<mailto:dsingh at adobe.com>>
Cc: Saleem Abdulrasool <abdulras at fb.com<mailto:abdulras at fb.com>>, Nick Lewycky <nicholas at mxc.ca<mailto:nicholas at mxc.ca>>, "llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>" <llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>>
Subject: Re: [LLVMdev] Support for Windows Phone 8.1

On Mon, Jun 23, 2014 at 2:22 AM, Damanjit Singh <dsingh at adobe.com<mailto: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<mailto:compnerd at compnerd.org>>
Date: Monday, 23 June 2014 6:49 am
To: Damanjit Singh <dsingh at adobe.com<mailto:dsingh at adobe.com>>
Cc: Saleem Abdulrasool <abdulras at fb.com<mailto:abdulras at fb.com>>, Nick Lewycky <nicholas at mxc.ca<mailto:nicholas at mxc.ca>>, "llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>" <llvmdev at cs.uiuc.edu<mailto: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<mailto:compnerd at compnerd.org>> wrote:
On Wed, Jun 18, 2014 at 9:09 AM, Damanjit Singh <dsingh at adobe.com<mailto: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<mailto:abdulras at fb.com>> wrote:

On Jun 8, 2014, at 10:46 PM, Damanjit Singh <dsingh at adobe.com<mailto: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<mailto: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>
<mailto:compnerd at compnerd.org><mailto: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>
<mailto:nicholas at mxc.ca><mailto: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>
        <mailto:dsingh at adobe.com> <mailto:dsingh at adobe.com>><mailto:dsingh at adobe.com%3E%3E>>         <mailto:dsingh at adobe.com>><mailto: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> <mailto:llvmdev at cs.uiuc.edu>
        <mailto:llvmdev at cs.uiuc.edu%20%3Cmailto:llvmdev at cs.uiuc.edu>><mailto: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> <mailto:llvmdev at cs.uiuc.edu>
        <mailto:llvmdev at cs.uiuc.edu%20%3Cmailto:llvmdev at cs.uiuc.edu>><mailto: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> <mailto: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> <mailto: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<mailto: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

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140626/8c025db5/attachment.html>