Re: ELF to COFF Convertor

> Ajit Sarnaik SC2202 <sarnaik@asic.mtv.nec.com> wrote:
> >I am trying to find if there exists an ELF to COFF convertor that not only
> >converts the execution sections such as text and data, but also the debug
> >information. Any help would be appreciated.


arnold@mathcs.emory.edu (Arnold D. Robbins) writes:
> The SparcLinux people early on had an ELF to a.out converter so people
> could do development under Solaris. More generally, the GNU binutils
> use a library called BFD (binary file description) for managing object
> file formats. One of the utils is called 'objcopy' that can be made to
> read one format and copy the file using another. If what you want
> isn't there already, it should not be hard to build from the base
> facilities that are there.
>
> You can get the current binutils from prep.ai.mit.edu, or any
> convenient GNU mirror.


One of the original people asking about ELF to COFF conversion (or
COFF to ELF) conversion, either here or in one of the other
newsgroups, was on an RS/6000. Note, that in the COFF space, there
are lots of COFF varients that have been extended in wild and wooly
ways from the original System V.3 COFF (to name 3 that have been used
in the past or are currently used, there is XCOFF on IBM/Mac/Be
systems, ECOFF on SGI, Mips, and DEC systems, and PE, which is used on
Windows NT systems).


In particular, for coversions between XCOFF and ELF on PowerPC
systems, it is nearly impossible. 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):


        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.


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


        3) Varargs/stdarg support is completely different between the V.4 and
PowerOpen/NT. In particular, PowerOpen/NT passes floating args in both
integer and floating registers, and uses the register save area to make
one contiguous area. The va_list type is a char *. V.4 never passes
floating arguments in integer registers. The registers used to hold
arguments are saved in a separate save area, and va_list is an array of
1 element of a structure that contains pointers to the stack and
register save area, and two char variables indicating how many integer
and floating point registers have been processed. In addition, bit 6
of the condition code register is set to 1 if floating point arguments
were passed, and 0 if they were not.


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


        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


        6) Where the LR/CR is stored on the stack is different in all three.


        7) The static chain (environment pointer) is in r31 for V.4 and r11 for
PowerOpen. NT doesn't have a defined register for passing the static
chain, so GCC uses r11.


        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.


        9) A long long passed as word 7 is not split between the stack and the
register under V.4.


      10) Alloca for V.4 must copy both the stack back chain and the return
address when extending the stack, while PowerOpen only copies the stack
back chain.


      11) PowerOpen and NT use function descriptors, and function pointers point
to the function descriptor. The real function name is prefixed by one
or two periods. V.4 has function pointers point to the actual function
(which is not prefixed).


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.


--
Michael Meissner, Cygnus Solutions (East Coast)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner@cygnus.com, 617-354-5416 (office), 617-354-7161 (fax)
--

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