Re: ELF to COFF Convertor (Jeff Jackson)
5 Mar 1997 21:39:09 -0500

          From comp.compilers

Related articles
ELF to COFF Convertor (1997-02-16)
Re: ELF to COFF Convertor (1997-02-27)
Re: ELF to COFF Convertor (1997-02-27)
Re: ELF to COFF Convertor (1997-03-01)
Re: ELF to COFF Convertor (Michael Meissner) (1997-03-01)
Re: ELF to COFF Convertor (1997-03-05)
Re: ELF to COFF Convertor (Michael Meissner) (1997-03-14)
Re: ELF to COFF Convertor (1997-03-18)
| List of all articles for this month |

From: (Jeff Jackson)
Newsgroups: comp.compilers
Date: 5 Mar 1997 21:39:09 -0500
Organization: I would rather be windsurfing.
References: 97-02-100 97-02-158 97-03-018
Keywords: linker

This is because XCOFF
> (PowerOpen/AIX/Mac) and ELF (V.4/eabi/Linux) PowerPC systems use
> different ABI's (and NT uses a slightly different ABI from AIX/Mac):

Actually there's more than one SVR4 implementation too, just to make
things more confusing.

Concurrent Computer Corporation (formerly Harris Computer Systems)
use SVR4 as the basis for their OS on NightHawk, Power Maxion, and
various Motorola PowerPC systems.

> 1) Only 8 floating point args are passed in registers in V.4 compared to
> 13 in PowerOpen and NT. Also under V.4, floating arguments passed in
> floating registers don't cause the corresponding integer registers to
> be skipped.

Concurrent passes 13 float registers, but regards only 8 of the remaining
as non-volatile.

> 2) V.4 has no register save area for the 8 words passed in GP registers.

Concurrent assigns a "register save area" slot to every parameter, whether
it is passed there or not. Concurrent never skips a register in passing
parameters in general or float registers. Floats are never passed in
general registers

> 3) Varargs/stdarg support is completely different between the V.4 and

Varargs/stdarg support in Concurrent uses a structure that contains
three pointers that are incremented through the "register save area"
and two arrays for holding general and float registers. The float
registers are not saved off when it can be determined at compile time
that no parameter was passed that way or if an option is given.

> 4) V.4 doesn't support a TOC register. The eabi extension uses it as a
secondary small data area.

Concurrent uses it as a frame pointer, when needed ala 88open.

> 5) V.4 uses r13 to point to the small data area, while PowerOpen uses it
> as a normal caller save register, and NT reserves it for use by the
> operating system. PowerOpen

I'm not sure what the "small data area" is. If you mean aggregate return
values, these are passed as a hidden first argument in Concurrent's

> 7) The static chain (environment pointer) is in r31 for V.4 and r11 for

I think Concurrent uses r11 for the static chain (I'm not an ADA geek,
so I'm not sure).

> 8) Under PowerOpen/NT, structures and unions are passed in registers or on
> the stack like large integers, while V.4 copies them to a temporary
> location and passes the pointer to that location.

Concurrent passes aggregates in contiguous registers, if there are enough
to pass the whole thing, otherwise, they are passed in on the stack
in their slots in the link area.

> In other words, you have the same sort of compatibility issues as
> going to a completely different machine and doing translation. It can
> be done, but it will take a lot of sweat and engineering.

I remember back end the days when we were targeting RIOS-1 (Power
without the PC). The OS wasn't done yet and I needed to test the
cross compiler. I wrote a program the munge the SVR4 compiler output
into AIX output. It even worked most of the time. However, it did
things very inefficiently, and there were some idioms (I don't
remember which ones) that just wouldn't translate. But, hey, it
worked good enough for my purposes.

I think you could probably write something that would transform an
executable much easier, so long as it only used standard shared
libraries (appropriate glue to be generated ad hoc for those).

On the other hand, in truely ancient days, on the Harris HCX machine,
in CX/UX release 7, we supported both COFF and ELF and provided tools
to convert from COFF to ELF. But the calling conventions were
identical and COFF at that time didn't have shared libraries to
deal with.
Jeffrey Glen Jackson

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.