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

[Ken Noland]

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/950e49d0/attachment.html>