82286 - Need xptcall port for intel compiler.

Status: RESOLVED WONTFIX

(Core :: XPCOM, defect, P4)

Description

[jim_nance]

I am playing around with the Beta of intel's C++ compiler for Linux.  It builds
mozilla, but there needs to be an xptcall port for this platform so that it will
run.  I talked to intel's technical support and got some information on the
compilers vtable layout.  Hopefully its enough.  I dont know intel asm.  Anybody
want to take a stab at this?  Here is the info they sent me:

- Our IA32 calling convention is the convention defined in the Unix ABI (as is
                       gcc; see http://www.sco.com/developer/devspecs/). For
member function calls, the
                       this pointer is treated as a hidden first argument and is
placed on the stack
                       (not in ecx as is done in the Windows environment). The
other arguments are also
                       placed on the stack. Integral or pointer return values
are placed in %eax.

                       - Each virtual function table entry has a size of 8
bytes. The 8 bytes are
                       partitioned as follows:

                       short d; // offset from this pointer required for call
                       short i; // no longer used
                       void (*f)(); // function to be called

                       - As for the offset of the virtual function pointer from
the start of a class,
                       our approach is very similar to what cfront does (we use
the EDG front-end and we
                       are using their model for our IA32 compiler). The virtual
function pointer is
                       added onto the end of a class requiring a vptr (this is
pretty much the opposite
                       of what Microsoft does). If you have the book "Inside the
C++ Object Model" by
                       Stanley B. Lippman (ISBN 0-201-83454-5), Section 4.2
provides a pretty good
                       example of what to expect.

                       If you are trying to build your application for the
Itanium processor, we are
                       conforming to the 64-bit C++ ABI specification (see
                       http://www.codesourcery.com/cxx-abi/). You can other
Itanium software convention
                       documents at
http://developer.intel.com/design/ia-64/under_lnx.htm.

                       I think this should answer most of your questions. If you
have other questions,
                       or require additional information, please let me know.

                       Let me know if this helps.

Comment 1

[John Bandhauer]

I suggest someone try digging up a voluteer. Platform ports come from people 
interested in the given platform who are willing to do the work to make mozilla 
work for them. There is already a bug in bugzilla specifically requesting an 
ia-64 port. Maybe someone with the interest, expertice, and desire will do the 
work one day.

Comment 2

[David Bradley]

I've futured this, but is there a better owner for this?

Comment 3

[David Bradley]

Might want to keep an eye on bug 40950

Also FWIW, there are a number of places where it is assumed that pointers are 32
bits. Any platform where this is not true will most likely fail.

Comment 4

[David Bradley]

This may actually not be an issue, as long as the size of the pointer is equal
to or less than type jsword aka long. The question is whether 64 bit compilers
treat long as 64 bits or 32 bits. If they're 64 bit, then all should be well.

Comment 5

[John Bandhauer]

The JS engine rule is that jsword is pointer sized. It is currently just
typedef'd to long on all platforms (AFAIK). If some platform comes along where
this is not correct then we'll need a platform specific #ifdefs for that
typedef. We *do* have other 64 bit platforms.

Comment 6

[Stuart Parmenter]

I'm working on it for ia32.

Comment 7

[William A. McArthur]

I'm looking forward to seeing this implemented.

Comment 8

[timeless]

re comment 5, while that may be the rule, it isn't actually the case (bug 226094)

Comment 9

[Andrew McCreight [:mccr8]]

It seems unlikely that we're going to fix this if we've gone without it for 16 years.