Support for Windows Phone 8.1

Project Infrastructure LLVM Dev List Archives
1

Hi LLVMdev,

Does the latest trunk code support Windows Phone 8.1 target ?

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 -emit–llvm a.c)

  • Create obj file – using llc - ./i686-apple-darwin11-llc -filetype=obj -mtriple=thumbv7-windows-msvc -O0 a.s

  • 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

2

Hi guys,

Would really appreciate any help here.

Thanks,
Daman

3

Damanjit Singh wrote:

Hi guys,

Would really appreciate any help here.

Thanks,
Daman

From: Damanjit Singh <dsingh@adobe.com <mailto:dsingh@adobe.com>>
Date: Friday, 6 June 2014 12:57 pm
To: "llvmdev@cs.uiuc.edu <mailto:llvmdev@cs.uiuc.edu>"
<llvmdev@cs.uiuc.edu <mailto:llvmdev@cs.uiuc.edu>>
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 -emit–llvm 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.

Nick

4

Damanjit Singh wrote:

Hi guys,

Would really appreciate any help here.

Thanks,
Daman

From: Damanjit Singh <dsingh@adobe.com <mailto:dsingh@adobe.com>>

Date: Friday, 6 June 2014 12:57 pm
To: "llvmdev@cs.uiuc.edu <mailto:llvmdev@cs.uiuc.edu>"
<llvmdev@cs.uiuc.edu <mailto:llvmdev@cs.uiuc.edu>>

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 -emit–llvm
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.

5

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.

Thanks,
Daman

6

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

7

Thanks a lot Saleem,

The issue is fixed and a simple app works fine now.

-Daman

8

Thanks a lot Saleem,

The issue is fixed and a simple app works fine now.

Awesome; thanks for the verification.

9

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.
  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.

I would really appreciate any help, or pointers for further investigation, for the second issue above.

Thanks,
Daman

10

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.

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.

11

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.

12

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?

Thanks,
Daman

13

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:
⚙ D3265 ARM: handle Windows specific relocations in CPI 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,

14

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

15

The issue is resolved now. It was my bad. I wasn’t setting the FunctionType correctly.

Thanks,
Daman