In article 18p@silver.jba.co.uk, JdeBP@jba.co.uk (Jonathan de Boyne Pollard) writes:
> Jason Merrill (jason@cygnus.com) wrote:
> : Currently the Sun ABI is the only game in town,
>
> If you mean (taking the context of your original post) by this that the Sun
> Application Binary Interface is the only publically available general
> description of a binary interface to classes and objects, then you're
> underinformed.
>
> There's also SOM (available on platforms as widely varying as OS/2 and the
> AS/400).
>
> And two DirectToSOM C++ compilers.

I find it difficult to classify SOM as a C++ ABI as it defines only one aspect
of C++ (the object model).  It also does not exactly map C++, since the object
model is actually slightly different from the C++ model.

This is not in any way a slam at SOM or DirectToSOM, just pointing out that it's
not even working on the same problem.

MetaWare, by the way, is one of those who have offered comments on the SunSoft
ABI.  Some of those comments have been incorporated in the ABI, by the way.


-Mike Ball-
SunSoft Developer Products.

Jason Merrill (jason@cygnus.com) wrote:
: Currently the Sun ABI is the only game in town,

If you mean (taking the context of your original post) by this that the Sun
Application Binary Interface is the only publically available general
description of a binary interface to classes and objects, then you're
underinformed.

There's also SOM (available on platforms as widely varying as OS/2 and the
AS/400).

And two DirectToSOM C++ compilers.

In article <MATT.95Jun5135309@godzilla.EECS.Berkeley.EDU>,
 <matt@physics.berkeley.edu> wrote:
>work.  Does anyone know if any pair of C++ compilers that produce
>binary-compatible object files actually exists?

 Sure. Metaware High C/C++ and IBM Cset++. (SOM)
Metaware High C/C++ and Watcom. Metaware and Microsoft.
Metaware and Borland.

 Whether these combinations link togther depends on
the name mangling convention (override in Metaware with pragma)
the kind of object file (Easy-OMF, Rational selectable in Metaware)
the calling conventions (selectable in Metaware) and other things
like RTTI and vtable layouts (some choices related to the
above exist).

 The best compatibility guarrantee appears to be
with Cset++ and High C/C++ operating DSOM (Direct to SOM).
Compatibility at other levels may be limited to "C" functions.

 Certainly ALL Windows and NT compilers have a level
of binary compatibility -- they all use the same kind of DLL
with a fixed kind of interface -- because they must to communicate
with the operating system.

 The answer therefore depends on exactly what you mean
by "binary-compatible" and how many pragmas you will allow
in the source files to fiddle things.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article 95Jun5135309@godzilla.EECS.Berkeley.EDU, matt@godzilla.EECS.Berkeley.EDU writes:
> Mangling comes up again and again in this group, and I honestly don't
> understand why.  How could anyone possibly imagine that mangling was
> the only thing that prevented binary compatibility?

Wishful thinking?

To provide some perspective, the Sun C++ ABI document is written as an
extension to the Sys V ABI, so it only covers C++ specific matters.  It's
also known to be incomplete as far as the latest changes to the standard,
so it can be expected to grow.  The sizes should give an impression of the
complexity.

Generic (machine-independent) parts 61 Pages
Sparc (machine-dependent) part  44 Pages
Rationale for Generic   33 Pages (and far too short)

This does NOT include a description of the C++ library, which should also be
considered part of the ABI.

Mike Ball
SunSoft Developer Products

In article <3r02n4$8pe@hermes.synopsys.com>,
Joe Buck <jbuck@synopsys.com> wrote:
>matt@physics.berkeley.edu writes:
>>Making two C++ compilers produce object files that were
>>binary-compatible would be a tremendous amount of work.
>
>I disagree (that it would be an enormous amount of work).  Given a well
>defined spec that describes the layout of each type of object, and
>assuming that nothing tricky is specified,

Do you consider the approach Mircosoft uses for vtable as tricky?
Remember, they think is was novel enough to get a patent on it.  Do
you consider the way g++ does exception handling as tricky?

Net result, they doesn't work together.

>modifying a C++ compiler to use this standard layout is not that hard
>a job.

Object layout is just a tiny portion of the total pie.

>Modifications would be on the level of "generate the vtable pointer
>first rather than last", "put the virtual base classes out in this
>order", etc.  Much simpler than, say, adding RTTI or namespaces.
>
>The first big hassle is getting everyone to agree to a common ABI.

Yes.  Everyone likes their own, and they don't feel any need to change
it.  Anyother problem is that while Suns C++ ABI is coming along
nicely, it still fails to allow .o from different places to be linked
together, and it fully specifies object layout!  Next contestent please.

One has to consider what can be allowed in header files, and what is
part of the interface, and what is part of the implementation.
Consider things like template repositories.


One day, this all will seem like a silly little problem...  :-)

In article 95Jun8145447@phydeaux.cygnus.com, jason@cygnus.com (Jason Merrill) writes:
>>>>>> Mike Stump <mrs@cygnus.com> writes:
>
>> Yes.  Everyone likes their own, and they don't feel any need to change
>> it.  Anyother problem is that while Suns C++ ABI is coming along
>> nicely, it still fails to allow .o from different places to be linked
>> together, and it fully specifies object layout!  Next contestent please.
>
>This sort of statement would be more useful if you actually said what was
>missing from the Sun C++ ABI.  My main problem with it is that it
>unilaterally specifies SunPro's implementation choices as The Standard; I'd
>prefer to see more of a committee design.

Sun's ABI's describe what Sun software does on SunOS and Solaris platforms.
Who should sit on a committee that decides how Sun implements its own
software?

As it happens, Sun invited numerous interested parties to comment on early
ABI drafts. Cygnus was among those invited, and Mike Stump attended a
meeting as I remember. Some of Sun's competitors were also invited and
attended. Sun of course cannot be bound by what its competitors (for example)
want Sun to do, but all suggestions and comments were taken very seriously.

The draft ABI (which is still incomplete) has been and still is available
to anyone who wants a copy, and comments are still being accepted. The
ABI is not complete partly because some of it depends on C++ committee
decisions which might yet change.
---
Steve Clamage, stephen.clamage@eng.sun.com

>>>>> Mike Stump <mrs@cygnus.com> writes:

> Yes.  Everyone likes their own, and they don't feel any need to change
> it.  Anyother problem is that while Suns C++ ABI is coming along
> nicely, it still fails to allow .o from different places to be linked
> together, and it fully specifies object layout!  Next contestent please.

This sort of statement would be more useful if you actually said what was
missing from the Sun C++ ABI.  My main problem with it is that it
unilaterally specifies SunPro's implementation choices as The Standard; I'd
prefer to see more of a committee design.

Jason

>>>>> Steve Clamage <clamage@Eng.Sun.COM> writes:

> In article 95Jun8145447@phydeaux.cygnus.com, jason@cygnus.com (Jason Merrill) writes:

>> This sort of statement would be more useful if you actually said what was
>> missing from the Sun C++ ABI.  My main problem with it is that it
>> unilaterally specifies SunPro's implementation choices as The Standard; I'd
>> prefer to see more of a committee design.

> Sun's ABI's describe what Sun software does on SunOS and Solaris platforms.
> Who should sit on a committee that decides how Sun implements its own
> software?

An ABI describes how different compilers should be able to interact on a
variety of platforms.  In particular, the Generic ABI is positioned as an
extension of the SVR4 ABI, applying to all SVR4 platforms, not just Sun
platforms.

I did not mean to imply that Sun should not be deciding how to write its
own software -- rather, since I develop a compiler that works for a wide
variety of targets, I would like to see the same ABI adopted on at least as
wide a basis as the SVR4 ABI is today.  I don't particularly mind changing
the compiler to comply with one ABI, but I would rather not have to deal
with different object layouts (for instance) on different platforms.

Currently the Sun ABI is the only game in town, and I doubt that it will
become accepted as a general standard any time soon, because it is
primarily Sun's work.  This is, of course, not Sun's fault, and I would
certainly like to commend Sun for making this effort.  And I may be wrong.

I would like to see more vendors either endorsing the Sun ABI effort or
offering their own alternatives.  This may be unrealistic.  As for me, I
expect g++ to adopt some parts of the Sun ABI for the 2.8 release cycle.

Jason

In article 95Jun8145447@phydeaux.cygnus.com, jason@cygnus.com (Jason Merrill) writes:
> >>>>> Mike Stump <mrs@cygnus.com> writes:
>
> > Yes.  Everyone likes their own, and they don't feel any need to change
> > it.  Anyother problem is that while Suns C++ ABI is coming along
> > nicely, it still fails to allow .o from different places to be linked
> > together, and it fully specifies object layout!  Next contestent please.
>
> This sort of statement would be more useful if you actually said what was
> missing from the Sun C++ ABI.  My main problem with it is that it
> unilaterally specifies SunPro's implementation choices as The Standard; I'd
> prefer to see more of a committee design.

SunPro offered the ABI as an initial proposal to a group of implementors and
library vendors.  Many have contributed to it, and there have been a lot
of changes since the first draft.  Many decisions are the result of of
the committee.  Many other decisions, particularly those that seemed to have
no practical disadvantages, were seen as good enough and left unmodified.

It's not just SunPro's design choices at all.  In fact, the ABI it defines
bears very little resemblance to the current SunPro compiler.

Mike Ball
SunSoft Developer Products (ne SunPro)

P. S.  If you only saw the first draft, you really haven't seen it at all.

In article <JASON.95Jun8145447@phydeaux.cygnus.com> jason@cygnus.com (Jason Merrill) writes:
>>>>>> Mike Stump <mrs@cygnus.com> writes:
>
>> Yes.  Everyone likes their own, and they don't feel any need to change
>> it.  Anyother problem is that while Suns C++ ABI is coming along
>> nicely, it still fails to allow .o from different places to be linked
>> together, and it fully specifies object layout!  Next contestent please.
>
>This sort of statement would be more useful if you actually said what was
>missing from the Sun C++ ABI.  My main problem with it is that it
>unilaterally specifies SunPro's implementation choices as The Standard; I'd
>prefer to see more of a committee design.
>

Sun is in the process of doing something that, to the best of my knowledge,
no other C++ vendor has ever done: publish their ABI so that others
can, if the so choose, conform to it.

I think Sun should be commended for doing this.  I hope other vendors
will join Sun in publishing this kind of information.

Sun has also made a concerted effort to involve others in the industry in
the process of reviewing the ABI.  They have reserved the right to
make the final choices, but that is certainly their right to do so.

Sure, it would be nice if *every* system vendor used a C++ ABI agreed
upon by a committee of compiler developers.  I'm not going to hold
my breath waiting for this to happen, though.

In the mean time, it is *great* that Sun publishing their ABI.  They
are investing a lot of time and effort in this process and should be
recognized for their effort.

John Spicer
Edison Design Group

In article <3ql4os$s9h@tools.near.net> barmar@nic.near.net (Barry
Margolin) writes:

|> Very few systems have a "native" C++ compiler.  Many system vendors don't
|> even include a C compiler with the system, much less a C++ compiler.

I think you mean `bundled'.  Systems without at least one native C++
compiler are rather the exception, but in most cases, you have to pay
to get it.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <D9JvFw.6Ez@lut.fi> hevi@dior.it.lut.fi (Petri Heinil{) writes:

> > Mangling is *deliberately* chosen to be different for incompatible
> > compilers on the same platform to avoid letting the users get themselves
> > in trouble.
>
> Making linking imcompatible, is good solution to prevent mix
> incompatible c++ object "engines".

Making mangling incompatiable is an entirely different question from
making linking incompatible.  Mangling is one tiny piece of the whole
binary compatibility issue.  Making two C++ compilers produce object
files that were binary-compatible would be a tremendous amount of
work.  Does anyone know if any pair of C++ compilers that produce
binary-compatible object files actually exists?

Mangling comes up again and again in this group, and I honestly don't
understand why.  How could anyone possibly imagine that mangling was
the only thing that prevented binary compatibility?
--
Matt Austern          matt@physics.berkeley.edu
http://dogbert.lbl.gov/~matt

matt@physics.berkeley.edu writes:
>Making mangling incompatiable is an entirely different question from
>making linking incompatible.  Mangling is one tiny piece of the whole
>binary compatibility issue.  Making two C++ compilers produce object
>files that were binary-compatible would be a tremendous amount of
>work.

I disagree (that it would be an enormous amount of work).  Given a well
defined spec that describes the layout of each type of object, and
assuming that nothing tricky is specified, modifying a C++ compiler to use
this standard layout is not that hard a job.  Modifications would be
on the level of "generate the vtable pointer first rather than last",
"put the virtual base classes out in this order", etc.  Much simpler
than, say, adding RTTI or namespaces.

The first big hassle is getting everyone to agree to a common ABI.
--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729

>>>>> matt  <matt@godzilla.EECS.Berkeley.EDU> writes:

> In article <D9JvFw.6Ez@lut.fi> hevi@dior.it.lut.fi (Petri Heinil{) writes:
>> > Mangling is *deliberately* chosen to be different for incompatible
>> > compilers on the same platform to avoid letting the users get themselves
>> > in trouble.
>>
>> Making linking imcompatible, is good solution to prevent mix
>> incompatible c++ object "engines".

> Mangling comes up again and again in this group, and I honestly don't
> understand why.  How could anyone possibly imagine that mangling was
> the only thing that prevented binary compatibility?

May I just interject that you all seem to be in violent agreement?

Jason

Petri Heinil{ (hevi@dior.it.lut.fi) wrote:

> Making linking imcompatible, is good solution to prevent mix
> incompatible c++ object "engines".

> But, general, thinking about interchangeablity of compilers.

OK, at this point, it's generally the vendor's responsibility to come up
with a sort of "C++ ABI", which should be a superset of the machine ABI,
and which will define object and virtual table layouts, and the like.

As to whether compiler vendors stick to this ABI or not, will depend
entirely on how much the different vendors' ABIs are similar to each
other..
--
Shankar Unni    E-Mail: shankar@sgi.com
Silicon Graphics Inc.   Phone: +1-415-390-2072
URL: http://reality.sgi.com/employees/shankar

In article <JASON.95Jun5143854@phydeaux.cygnus.com>,
Jason Merrill <jason@cygnus.com> wrote:
>May I just interject that you all seem to be in violent agreement?

No.  You may not.  That would be against the USENET way :-)

[[ As an aside: most people have no clue about how a compiler works, and when
   the names are mangled differently, they think it must be the only reason
   why the compilers won't work together.  While many clueful people know
   better, many do not.  ]]

Warner
--
Warner Losh  "VMS Forever"  home: imp@village.org
Cyberspace Development, Inc   work: imp@marketplace.com
Makers of TIA, The Internet Adapter.  http://marketplace.com/

In article <3qlrr3$k18@hermes.synopsys.com>, jbuck@synopsys.com (Joe Buck) writes:
> hevi@dior.it.lut.fi (Petri Heinil{) writes:
> >Some, say, mangling coneverter. Ii takes the object file generated by e.g.
> >g++, parses it and looks the mangeled names, and feeds the names into
> >g++-demangle, that is feeded into cront-mangle, and those manglet names
> >are then replaced into object file.

I had indeed too old copy of that FAQ.

> Read the FAQs to either comp.lang.c++ or gnu.g++.help.  This won't work.
> You can get the programs to link, but then they'll crash when you run them
> because the layout of virtual function tables, multiply inherited objects,
> etc, is different so virtual function calls will jump off into random
> memory.
>
> Mangling is *deliberately* chosen to be different for incompatible
> compilers on the same platform to avoid letting the users get themselves
> in trouble.

Making linking imcompatible, is good solution to prevent mix
incompatible c++ object "engines".

But, general, thinking about interchangeablity of compilers.

For example, can a operating system (kernel,mm,fs, or all basic modules)
be made by c++ ? If OS is made by cfront, how I can use g++ on it, and
vice versa ?

--
<A HREF="http://www.lut.fi/~hevi/">Petri.Heinila@lut.fi</A>

hevi@dior.it.lut.fi (Petri Heinil{) writes:
>Some, say, mangling coneverter. Ii takes the object file generated by e.g.
>g++, parses it and looks the mangeled names, and feeds the names into
>g++-demangle, that is feeded into cront-mangle, and those manglet names
>are then replaced into object file.

Read the FAQs to either comp.lang.c++ or gnu.g++.help.  This won't work.
You can get the programs to link, but then they'll crash when you run them
because the layout of virtual function tables, multiply inherited objects,
etc, is different so virtual function calls will jump off into random
memory.

Mangling is *deliberately* chosen to be different for incompatible
compilers on the same platform to avoid letting the users get themselves
in trouble.
--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729

Hi.

I am very new to g++.
I'm just understanding about name mangling.
I have read in the g++ FAQ why g++ mangles names differently from other
C++ compilers.  The explanation leads me to believe that code compiled
with gcc2.6.3 can never be linked with code compiled with a native C++
compiler.  Is that, in fact true?

We have installed g++ and gas on our HP machine and have compiled
existing code with g++ and the native HP C compiler.  We want to merge
a C++ package with this existing code.  This package requires compilation
with the native HP C++ compiler and contains libraries created with the
native HP C++ compiler.  We were hoping to compile the code separately
and then link objects together.

Although we have successfully linked objects compiled under g++
with objects compiled under the native HP C compiler, we have not
been able to link with the C++ object files.
Can any one offer any advice on linking together such object files?


Any help is greatly appreciated.


-- brian

In article <1995May31.232322.1398@nosc.mil>, "Brian A. Hardy" <bhardy@cod.nosc.mil> writes:
> I have read in the g++ FAQ why g++ mangles names differently from other
> C++ compilers.  The explanation leads me to believe that code compiled
> with gcc2.6.3 can never be linked with code compiled with a native C++
> compiler.  Is that, in fact true?

Yes, the mangled procedure entries in object files are different.

> We have installed g++ and gas on our HP machine and have compiled
> existing code with g++ and the native HP C compiler.  We want to merge
> a C++ package with this existing code.  This package requires compilation
> with the native HP C++ compiler and contains libraries created with the
> native HP C++ compiler.  We were hoping to compile the code separately
> and then link objects together.

This indeed makes life uneasy, or yet forces to use some vendor
compiler, just for reason the library is compiled with it.

> Although we have successfully linked objects compiled under g++
> with objects compiled under the native HP C compiler, we have not
> been able to link with the C++ object files.

In general, there could be couple of solutions:

Some, say, mangling coneverter. Ii takes the object file generated by e.g.
g++, parses it and looks the mangeled names, and feeds the names into
g++-demangle, that is feeded into cront-mangle, and those manglet names
are then replaced into object file.

I don't know if there exist any this kind of converter.

Other, maybe better, is standardization activity to fix the format
of mangling. Is there any ?

--
<A HREF="http://www.lut.fi/~hevi/">Petri.Heinila@lut.fi</A>

In article 56B@lut.fi, hevi@dior.it.lut.fi (Petri Heinil{) writes:
>In article <1995May31.232322.1398@nosc.mil>, "Brian A. Hardy" <bhardy@cod.nosc.mil> writes:
>> I have read in the g++ FAQ why g++ mangles names differently from other
>> C++ compilers.  The explanation leads me to believe that code compiled
>> with gcc2.6.3 can never be linked with code compiled with a native C++
>> compiler.  Is that, in fact true?
>
>Yes, the mangled procedure entries in object files are different.
>
>
>In general, there could be couple of solutions:
>
>Some, say, mangling coneverter. Ii takes the object file generated by e.g.
>g++, parses it and looks the mangeled names, and feeds the names into
>g++-demangle, that is feeded into cront-mangle, and those manglet names
>are then replaced into object file.

Among differences in C++ compilers, the differences in name mangling
are the LEAST important. If you "fix" the name mangling, the resulting
code might link, but will crash when you try to run it. The FAQ list
was just posted yesterday. See Q124: "If name mangling was standardized,
could I link code compiled with compilers from different compiler vendors?"

---
Steve Clamage, stephen.clamage@eng.sun.com

In article <1995May31.232322.1398@nosc.mil> "Brian A. Hardy" <bhardy@cod.nosc.mil> writes:
>I am very new to g++.
>I'm just understanding about name mangling.
>I have read in the g++ FAQ why g++ mangles names differently from other
>C++ compilers.  The explanation leads me to believe that code compiled
>with gcc2.6.3 can never be linked with code compiled with a native C++
>compiler.  Is that, in fact true?

Very few systems have a "native" C++ compiler.  Many system vendors don't
even include a C compiler with the system, much less a C++ compiler.

But I think the main reason for such incompatibilities is that most system
vendors don't publish a standard for C++ object layout, name mangling, and
calling sequences.  So each compiler implementor has to define all these
things for themselves.  So even if two compilers used the same name
mangling scheme, they might still use different vtable formats or pass
--
Barry Margolin
BBN Planet Corporation, Cambridge, MA
barmar@{bbnplanet.com,near.net,nic.near.net,netcom.com}
Phone (617) 873-3126 - Fax (617) 873-5124