[LLVMdev] Unifying Windows Target Triples

[David Majnemer]

Win32 is not an ABI.  If one were to compile an NT driver, they wouldn't be
targeting win32. They would be targeting windows.
On Fri Feb 28 2014 at 12:03:32 AM, NAKAMURA Takumi <geek4civic at gmail.com>
wrote:

> Saleem,
>
> 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)
>   - PE/COFF
>   - 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++.
>
> * x86_64-pc-cygwin
>   - LP64
>   - 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)
>
> ...Takumi
>
>
> 2014-02-28 12:40 GMT+09:00 Saleem Abdulrasool <abdulras at fb.com>:
> > Hi,
> >
> > 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:
> >
> > {armv7,i686,x86_64}-windows-{ia,mingw,ms}pe
> >
> > 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
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140228/a74c8e40/attachment.html>