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

[Francois Pichet]

The problem is how do we deal with predefined macros that depend on
cl.exe specific compiler switches? Almost all MSVC predefined macros
fit this category.

What I am planning to do is to write a cl2clang driver that would act
as a cl.exe (MSVC) drop-in replacement. That driver would accept the
same set of options as cl.exe
(http://msdn.microsoft.com/en-us/library/fwkeyyhe%28VS.71%29.aspx).
Translate those options (including setting predefined macros with -D)
to be clang compatible and spawn a new clang process.

Since  Visual studio 2010 is now using msbuild to build C++ projects,
I think it would be possible to do something like:
msbuild /p:VCBuildToolPath=cl2lang.exe mysolution.sln

And use the whole MSVC build system and just have clang do the compilation.

Anybody think it would be useful to put that new cl2lang driver into
the mainline repository?
It is just an idea for now.. I haven't started working on it.


2010/8/17 Chris Lattner <clattner at apple.com>:
> Thanks Per, I applied your two patches.    It would be nice if someone would compare the list of macros predefined by MSVC with the list of macros predefined by clang (when targeting windows).  Instead of trusting the MS docs, it would be good to find a way to get MSVC to dump its macro table.
>
> -Chris
>
> On Aug 11, 2010, at 9:11 AM, per at lumai.se wrote:
>
>> 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
>>
>> --
>> Per Lindén
>> <DefineSTDCALLSUPPORTED.patch><StopEmittingFIXME.patch>_______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>