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>
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140623/7ddbd043/attachment.html>
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>
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>
The issue is resolved now. It was my bad. I wasn’t setting the FunctionType
correctly.
Thanks,
Daman
From: Damanjit Singh <dsingh at adobe.com<mailto:dsingh at
adobe.com>>
Date: Thursday, 26 June 2014 10:03 am
To: Saleem Abdulrasool <compnerd at compnerd.org<mailto:compnerd at
compnerd.org>>
Cc: "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
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/51045deb/attachment.html>