[cfe-dev] PE/COFF for MIPS

[Martin Storsjö via cfe-dev]

On Wed, 26 Feb 2020, valerij zaporogeci via cfe-dev wrote:

> My OS is going to be NT-like and have WinAPI-like environment. So,
> it's like Windows appeared again on MIPS, right. :D would it be too
> hard for one to "look how it's done for the x86 and generilze
> farther"?

It's not very hard but requires some work. The same has been done for 
AArch64 in the last few years - see e.g. 
0c72172e320f77380ad2562d2dfe1abb14a25e1c for the initial commit for that 
effort.

> And yet. Say, I reached the stage, where I want to bring a compiler
> for my OS. Is clang/llvm friendlier to WinAPI platforms, than gcc for
> porting to a WinAPI-like environment? meaning does this port relies on
> WinAPI in as much respects as any native program would have, written
> for that API or does it demand that the environment looked like POSIX?
> I mean, why gcc needs those MinGW/Cygwin stuff instead of just using
> what is on the platform - after all a compiler requires not much from
> the host system.

If we first put Cygwin aside - gcc doesn't need cygwin for targeting 
windows - Cygwin is there for being able to port apps that use a lot of 
POSIX specific APIs to run on top of Windows.

GCC doesn't really need MinGW because of a need to generate calls to POSIX 
like APIs; after all, the compiler generally generates very few calls to 
system functions automatically.

In that respect, GCC primarily needs MinGW for two or three reasons: 
First, because the official Windows SDK isn't redistributable and free 
software - so MinGW fills the role as a freely redistributable 
reimplementation of a Windows SDK. And secondly, the Windows SDK headers 
use a number of MSVC specific language extensions which GCC doesn't 
support, so in that respect, MinGW is an SDK with GCC friendly headers.

On top of that, MinGW provides just a couple extra POSIX-derived APIs 
(usleep, getopt and a couple ones - that don't require a runtime but that 
just are statically linked) for easing porting of some apps, not strictly 
necessary for GCC for generating code for it (but maybe useful for 
building GCC itself for that target).

Clang and LLVM can emulate both GCC and MSVC personalities in this aspect, 
so I'd say it's a good place to start off, so you have all options 
available. And speaking from experience, I'd say it's fairly 
straightforward to add support for windows style COFF on a new 
architecture in the LLVM libaries and tools. Although I haven't really 
made an equally big effort in GCC/binutils so I don't know for sure, but 
initial peeks into it made it look like a much more complex task there.

// Martin