PE/COFF for MIPS

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

PE/COFF for MIPS

suyash singh via cfe-dev
Hi. Is it possible to have a clang/llvm build that both would support
MIPS architecture and PE/COFF format for object files and executables?
without the need to change the code base, of course. just with proper
configuration. So that one can use PE DLL import/export for modules
instead of ELF shared objects. Initially I have been thinking on
creating an ELF->PE translator, but it quickly became obvious, that
it's not practical - because it's the compiler, that needs to
understand declspec(dllimport/dllexport).
I am not a compiler guy, so making changes in such huge projects as
gcc or clang are out of my scope. I am working on firmware/osdev hobby
projects for a mips32r2 board (among ARM ones) and would be very happy
to use such a familiar, useful and handy PE/COFF format for
executables.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: PE/COFF for MIPS

suyash singh via cfe-dev
Hi,

I think it's a rather difficult task. We need to create COFF object
file writer for MIPS backend and support linking of COFF files in LLD
linker. Now MIPS backend expects ELF output format only. For COFF we
also have to change a code generator because some features cannot be
implemented in COFF.

On Mon, Feb 24, 2020 at 5:41 AM valerij zaporogeci via cfe-dev
<[hidden email]> wrote:

>
> Hi. Is it possible to have a clang/llvm build that both would support
> MIPS architecture and PE/COFF format for object files and executables?
> without the need to change the code base, of course. just with proper
> configuration. So that one can use PE DLL import/export for modules
> instead of ELF shared objects. Initially I have been thinking on
> creating an ELF->PE translator, but it quickly became obvious, that
> it's not practical - because it's the compiler, that needs to
> understand declspec(dllimport/dllexport).
> I am not a compiler guy, so making changes in such huge projects as
> gcc or clang are out of my scope. I am working on firmware/osdev hobby
> projects for a mips32r2 board (among ARM ones) and would be very happy
> to use such a familiar, useful and handy PE/COFF format for
> executables.

--
Simon Atanasyan
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: PE/COFF for MIPS

suyash singh via cfe-dev
I think there's also a broader question of 'which COFF'.  A lot of the
LLVM code assumes that COFF approximates to Windows.  If the goal is to
target NT 4 or WinCE, which both had MIPS ports, then it's some work but
it's largely a matter of adapting the code in the x86 and ARM back ends.
  There are (were?) also a number of *NIX MIPS systems that used COFF as
their binary format and these have very little in common with the
Windows format (other than the container structure).  Relocation types
are different, the C++ ABI is different and there are probably some
other differences.  If this is for a hobby OS, what are the requirements?

As I recall, Sony has some changes to clang/llvm/FreeBSD-rtld to support
dllimport / dllexport in ELF binaries.  If this is the requirement, then
perhaps asking them to upstream them would be a simpler solution?  As I
recall, they were private because they didn't think anyone else wanted
them, rather than because they involved any competitive advantage.

David


On 24/02/2020 09:50, Simon Atanasyan via cfe-dev wrote:

> Hi,
>
> I think it's a rather difficult task. We need to create COFF object
> file writer for MIPS backend and support linking of COFF files in LLD
> linker. Now MIPS backend expects ELF output format only. For COFF we
> also have to change a code generator because some features cannot be
> implemented in COFF.
>
> On Mon, Feb 24, 2020 at 5:41 AM valerij zaporogeci via cfe-dev
> <[hidden email]> wrote:
>>
>> Hi. Is it possible to have a clang/llvm build that both would support
>> MIPS architecture and PE/COFF format for object files and executables?
>> without the need to change the code base, of course. just with proper
>> configuration. So that one can use PE DLL import/export for modules
>> instead of ELF shared objects. Initially I have been thinking on
>> creating an ELF->PE translator, but it quickly became obvious, that
>> it's not practical - because it's the compiler, that needs to
>> understand declspec(dllimport/dllexport).
>> I am not a compiler guy, so making changes in such huge projects as
>> gcc or clang are out of my scope. I am working on firmware/osdev hobby
>> projects for a mips32r2 board (among ARM ones) and would be very happy
>> to use such a familiar, useful and handy PE/COFF format for
>> executables.
>
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: PE/COFF for MIPS

suyash singh via cfe-dev
In reply to this post by suyash singh via cfe-dev
On Feb 23, 2020, at 9:40 PM, valerij zaporogeci via cfe-dev <[hidden email]> wrote:
>
> I am not a compiler guy, so making changes in such huge projects as
> gcc or clang are out of my scope. I am working on firmware/osdev hobby
> projects for a mips32r2 board (among ARM ones) and would be very happy
> to use such a familiar, useful and handy PE/COFF format for
> executables.

If you have a choice in the matter, just use ELF. It’s the most well-trod path.

Up to this point in your message, I thought you might be trying to target Windows NT for MIPS with a modern compiler. I suspect in that case what you’d want to do is look at how the PE/COFF support is implemented for Windows 32- and 64-bit x86, and see how much of that could be generalized to “any Windows platform.”

  -- Chris

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: PE/COFF for MIPS

suyash singh via cfe-dev
In reply to this post by suyash singh via cfe-dev
Thank you all for your replies.

To David.
>  If this is for a hobby OS, what are the requirements?
The requirement would be "pretty much the same as Windows NT for MIPS has".

To Chris.
> If you have a choice in the matter, just use ELF. It’s the most well-trod path.
Let's take shared objects. I want to make the kernel modular - not
with just object files delay-linked, but as real modules which can
import/export and be easily loaded, unloaded. they would be loaded
into "the same" kernel part of any process address space, why do I
need PIC? it's just a waste of CPU in this situation. there no
advantage of having them PIC. but can I make shared objects non PIC?
still capable of importing from and exporting to other modules - not
just kernel, with interdepencies, is it possible with such imaginable
ELF non-PIC shared objects? If I will use ELF "executable" for them, I
frankly have no idea of how then make them import/export without ugly
trickery. Of course, I lack skilled knowledge of all the nuances of
ELF, maybe it's doable and I hope so, as a temporary solution, it
still looks much optimistic than modifying clang/llvm, which I'd
happily do if it weren't a gigantic thing one needs to spend a lot of
time staring at just to have a slight idea of its nature.

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"? Actually, it was my initial question, I just forgot to say
that the platform is "like Windows".

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.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: PE/COFF for MIPS

suyash singh 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

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev