[cfe-dev] Windows .exe from clang + COFF w/o gcc - success with issues

[Ken Noland]

Also, it appears to help if you put the word [PATCH] in the title

Cheers,
-Ken Noland

On Mon, Aug 16, 2010 at 10:38 AM, Ken Noland <nippbit at gmail.com> wrote:

> Hey,
>
> I'm new on this list, but earlier I caught a thread about similar issues.
> Check out the thread "CLang compiling windows.h from the Windows SDK" from
> Francois Pichet.
>
> If I understand this correctly, there are a lot of things about the windows
> headers that are not going to be easy fixes. However, I'm interested in
> doing the same thing; getting CLang to compile a windows executable.
> Personally, I prefer Doug's recommended way of dealing with other companies
> or projects that are not compliant, by telling them to correct their
> headers, but who knows how long that will take until MS finally get around
> to fixing them.
>
> I'll check out this patch later tonight and see what results I get and post
> my results back here. Can someone with commit rights check out the patch as
> well?
>
> Thanks,
> -Ken Noland
>
> 2010/8/16 per at lumai.se <per at lumai.se>
>
>> Ping? Does anyone feel like taking a look at these patches? Should I
>>
>> submit any bugs for the issues below?
>>
>> --
>> Per Lindén
>>
>> per at lumai.se skrev 2010-08-11 18:11:
>> > Hi all,
>> >
>> > I have been experimenting with the creation of Win32 executables using
>> > only MSVC SDK headers, clang, llc and link.exe from MS Visual Studio
>> > 2008. This has uncovered a few issues:
>> >
>> > 1) VisualStudioWindowsX86_32TargetInfo needs to define
>> > _STDCALL_SUPPORTED. Otherwise the Win32 API does not get dllimport
>> > declarations and linking fails. Patch attached.
>> >
>> > 2) The SDK include directory search fails for me.
>> > InitHeaderSearch.cpp:getWindowsSDKDir() uses key "InstallationFolder"
>> > whose contents lacks the final "\include" needed for SDK 6.0a.
>> >
>> > 3) Compiling the simple test program below causes the resulting llvm
>> > assembly to include definitions of the functions Int64ShllMod32,
>> > Int64ShraMod32 and Int64ShrlMod32 although these are neither used or
>> > referenced in the code. This in turn causes problems in 4):
>> >
>> > define x86_stdcallcc i64 @Int64ShllMod32(i64 %Value, i32 %ShiftCount)
>> > nounwind inlinehint {
>> > entry:
>> > %retval = alloca i64, align 8 ; <i64*> [#uses=1]
>> > %Value.addr = alloca i64, align 8 ; <i64*> [#uses=1]
>> > %ShiftCount.addr = alloca i32, align 4 ; <i32*> [#uses=1]
>> > store i64 %Value, i64* %Value.addr
>> > store i32 %ShiftCount, i32* %ShiftCount.addr
>> > call void asm sideeffect "FIXME: not done",
>> > "~{dirflag},~{fpsr},~{flags}"() nounwind, !srcloc !0
>> > %0 = load i64* %retval ; <i64> [#uses=1]
>> > ret i64 %0
>> > }
>> >
>> > 4) Parser::FuzzyParseMicrosoftAsmStatement() emits "FIXME: not done" in
>> > the llvm code above when microsoft assembly is encountered. Changing it
>> > to emit "/*"FIXME: not done*/" makes the resulting file compile. Patch
>> > attached.
>> >
>> > ***
>> >
>> > The final Win32 executable works when fixes for the stuff above are
>> > applied...! I personally find this very cool. Steps to reproduce:
>> >
>> > Create test.c:
>> >
>> > #include <windows.h>
>> > int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
>> > lpCmdLine, int nCmdShow) {
>> > MessageBox(NULL, "hello msgbox world\n", "Title", MB_OK);
>> > return 0;
>> > }
>> >
>> > Run (in the "Visual Studio 2008 Command Prompt" or another working MSVC
>> > environment):
>> >
>> > clang -I <path to SDK/include> -D_STDCALL_SUPPORTED -c -emit-llvm test.c
>> > llc -filetype obj test.o -o test.obj
>> > link test.obj user32.lib msvcrt.lib
>> >
>> > link.exe = the MSVC linker
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100816/3eed62c4/attachment.html>