Re: Class layout accross multiple architectures.

[Nathan Myers <ncm at nospam dot cantrip dot org>]

Ben Scherrey wrote:
> Just how large a difference is
> there between the object layouts of various hardware/OS implementations
> of egcs? I guess the first platforms we'd like to support are probably
> Linux/Intel, Solaris/SPARC, and HP/Ux on
> whatever-processor-is-in-the-9000. I suspect that some areas should be
> pretty consistent but that others will be entirely platform dependent.
> Is it possible to effectively abstract out these layouts?

Egcs matches each platform's C ABI in its layout for C-compatible structs 
(what we in C++ call PODs, for "plain ol' data", by analogy with standard 
telephone terminology: "POTs").  It departs from that for features only 
not supported in C.

In addition, there are two C++ ABIs per target: the one in current compilers 
and an experimental one, the current version of which is obtainable with
the compiler option "-fnew-abi".  When this last is ready it will become 
the default (sometime early next year, perhaps), and will then be stable 
at least until the standard revision C++200x (x > 3) is released.

Therefore, supporting Egcs on your various targets may be less work than
you might have expected: you can use the same layouts for C structs (PODs) 
as are used in your current product on each platform; only the C++ 
extensions differ, but are consistent from platform to platform according 
to the C conventions for that platform.

For example, instances of a class with virtual functions will contain a 
"vptr", a pointer to a "vtable", represented according to the conventions 
for a struct member of a pointer type on that platform.  The vtable will 
look like an array of structs laid out conventionally for that platform. 

If I understand correctly, the differences between Egcs's old and "new-abi" 
as it affects you are mainly in 

(1) the contents of the vtable and what it points to, 
(2) object layout in the presence of empty subobjects (old-abi subobjects
    are never really empty) and virtual bases, and
(3) name mangling.

Of course the RTTI and exception state table layouts are completely different,
but I don't expect that will affect you much.

Nathan Myers
ncm@cantrip.org