[cfe-dev] PE/COFF for MIPS
Martin Storsjö via cfe-dev
cfe-dev at lists.llvm.org
Tue Feb 25 23:50:29 PST 2020
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
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
> 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.
More information about the cfe-dev