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

[Michael Spencer]

On Fri, Aug 20, 2010 at 8:04 PM, Cameron Esfahani <dirty at apple.com> wrote:
> Does that version support X86_64?  I would've expected to see _M_AMD64...

I have not gotten around to disassembling the 64 bit compiler yet
(yes, it's a separate compiler), but _M_X86 and _M_AMD64 are defined
when compiling with the x64 compiler.

I've attached a patch for review that fixes most of the predefined
macros on windows. I can compile hello world and parts of Lua.

- Michael Spencer

> On Aug 20, 2010, at 12:21 PM, Michael Spencer wrote:
>
>> 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
>>
>> Using IDA I got the compiler to print out every macro it defines, I
>> haven't gotten it to spit out the expansion, but that's easy to get
>> without IDA.
>>
>> __FILE__
>> __DATE__
>> __TIME__
>> __TIMESTAMP__
>> __VA_ARGS__
>> __FUNCTION__
>> __FUNCDNAME__
>> __FUNCSIG__
>> __FSTREXP
>> __LPREFIX
>> __APREFIX
>> __COUNTER__
>> _MSC_EXTENSIONS
>> _INTEGRAL_MAX_BITS
>> _MSC_VER
>> _MSC_FULL_VER
>> _MSC_BUILD
>> _WIN32
>> _M_IX86
>> _M_IX86_FP
>> _MT
>>
>> Interestingly, _STDCALL_SUPPORTED is not in this list. I expected this
>> due to the string not being in any of the binaries and it not
>> expanding to anything using the compiler normally.
>>
>> MSVC has two separate binaries for c and c++, so I'll have to
>> duplicate this in the c++ case, but it should be easy now that I know
>> the global variable they use to pass identifiers around. (For anyone
>> that wants to take a look. They are in c1.dll and the function is
>> <.text:4F057EC0 ?InstallDefine@@YIXPAEHH_N at Z proc near> and the
>> variable is <.data:4F0B5800 ?pCurId@@3PAUId_t@@A dd>).
>>
>> ?pCurId@@3PAUId_t@@A is a pointer to a struct where the second dword
>> is a pointer to the identifier string. You can use
>> GetString(Dword(Dword(LocByName("?pCurId@@3PAUId_t@@A"))+4), -1,
>> ASCSTR_C) while debugging a program in IDA to get the string.
>>
>> I'll collect all the defines for c and c++ with the various compiler
>> options and put them all up someplace.
>>
>> - Michael Spencer
>>
>>>
>>> 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
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
> Cameron Esfahani
> dirty at apple.com
>
> "In the elder days of Art, Builders wrought with greatest care each minute and unseen part; For the gods see everywhere."
>
> "The Builders", H. W. Longfellow
>
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: commit-fix-predefines
Type: application/octet-stream
Size: 7301 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100821/8378cab0/attachment.obj>