[LLVMdev] Unifying Windows Target Triples
geek4civic at gmail.com
Thu Feb 27 23:59:53 PST 2014
Thanks to open the Pandora's box!
I am certain "Win32" should be common word to represent Win32 API (ABI
in some context).
Then, I preferer -win32- rather than -windows-.
If we could use *-win32, I hope it might be neutral as possible.
That said, I don't have concrete plan what *-win32 should be.
In other words, I think it'd be worse that "*-pc-win32" represents
whole msvc things.
I could make the matrix later. This is a random note.
* i686-pc-cygwin (gcc-4.x)
- Win32 compatible. Win32 API(s) could be available with <windows.h>.
- Doesn't use thiscall.
- Doesn't use msvcrt. Using newlib delivered.
- Uses GNU libstdc++ and libsupc++.
- Uses dw2 eh.
* i686-pc-mingw32 (<4.6)
- Uses msvcrt.dll. (malloc is not 16-byte aligned). Other versions
of msvcrt are optional.
- Uses some supplemental libs that incapable in msvcrt.dll.
- Uses libgcc
- Uses GNU libstdc++ and libsupc++ provided by g++ (lib/gcc/i686-pc-mingw32)
- Doesn't use thiscall.
- dw2 is available older version of mingw32 was available only sjlj.
* *-w64-mingw32 (>=4.6)
- Uses msvcrt.dll even on x86_64 (!!!)
- EH is optional, x64-comptatible eh (aka seh) may be available.
- multilib is available in development environment.
- Uses thiscall (for i686)
- Uses GNU libstdc++.
- Investigating :p
I wonder if we could provide neutral *-win32 for our project, or naked
*-win32 might be used as non-C++ environments...
(Consider with compiler-rt, libcxxabi and libcxx)
2014-02-28 12:40 GMT+09:00 Saleem Abdulrasool <abdulras at fb.com>:
> After a discussion with David, Id like to propose a rework of the Windows target triples. The current set of Windows triples are somewhat less uniform than their Linux counterparts. With multiple ABIs and environments on Windows, they are also slightly awkward. Obviously, certain ones might be nice to keep around for compatibility (e.g. the mingw triple).
> Just to ensure that everyone has the same understanding, the canonical format for a triple is: arch-vendor-os-environment .
> We have the following environment on Windows:
> As far as I know, everyone conforms to the MS C ABI.
> - There is the MS C++ ABI which is still being developed.
> - There is the IA-64 ABI which is incompatible with msvcprt.
> - There is the MinGW sub environment which supplies additional UNIX-y functions and uses IA-64 ABI for C++.
> The Windows environment is uniformly (COFF)/PE.
> As for the OS, Windows is slightly generic. Windows 9x, Windows NT, and Windows CE are all slightly different. However, given that Microsoft has taken a unifying strategy with Windows NT, I *think* sticking to Windows for the OS should be okay. That said, I could be convinced to use winnt or windowsnt.
> So, one way to clearly define a naming scheme for this space would be something along the lines of:
> This allows us to uniformly take any of the combination IA-64 or MS C++ ABI + MS C ABI or the MinGW environment (which is IA-64 ABI and its supplementary libraries).
> I understand that this may be controversial since it can potentially break existing code bases, but I think that the result of this is worth it.
> Saleem Abdulrasool
> abdulras (at) fb (dot) com
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev