Date: Thu, 18 Jul 2024 08:17:08 -0700
On Thursday 18 July 2024 07:13:57 GMT-7 Hans via Std-Proposals wrote:
> That is only relevant if multiple ABIs coexist within a platform. Do
> such platforms exist? What is the purpose of having a C++ compiler on a
> platform if you can't even call into any platform libraries?
They do exist and they have the same C ABI.
They don't have the same C++ ABI. There are no platform C++ libraries on
Windows: they all have a C ABI. Strictly speaking, on 32-bit x86, they don't
even have a C ABI, they have a stdcall ABI.
And even in the C ABI, there are discrepancies (see GCC's option for
"microsoft bitfields").
There used to exist more such platforms. On Solaris, Sun's C++ compiler
produced an ABI that was incompatible with GCC. Moreover, their compiler
supported two different Standard Libraries (Sun's and stlport), so on Solaris
you effectively had three different ABIs to deal with. Ditto for IRIX, for SGI's
compiler and GCC's, and on PA-RISC based HP-UX for HP aCC and GCC. But not on
HP-UXi, because that "i" stood for Itanium and HP aCC started using the IA-64
ABI.
Microsoft is the last remaining, relevant hold out.
There may be other compilers not producing the IA-64 C++ ABI. For example, I
have no clue what Green Hills' compiler produces, but since everything on
INTEGRITY is compiled into a single, statically-linked executable that runs in
kernel mode (it is your kernel), you must use the same compiler for
everything. And besides, if you're paying to use INTEGRITY, why would you not
use GHS' compiler?
> That is only relevant if multiple ABIs coexist within a platform. Do
> such platforms exist? What is the purpose of having a C++ compiler on a
> platform if you can't even call into any platform libraries?
They do exist and they have the same C ABI.
They don't have the same C++ ABI. There are no platform C++ libraries on
Windows: they all have a C ABI. Strictly speaking, on 32-bit x86, they don't
even have a C ABI, they have a stdcall ABI.
And even in the C ABI, there are discrepancies (see GCC's option for
"microsoft bitfields").
There used to exist more such platforms. On Solaris, Sun's C++ compiler
produced an ABI that was incompatible with GCC. Moreover, their compiler
supported two different Standard Libraries (Sun's and stlport), so on Solaris
you effectively had three different ABIs to deal with. Ditto for IRIX, for SGI's
compiler and GCC's, and on PA-RISC based HP-UX for HP aCC and GCC. But not on
HP-UXi, because that "i" stood for Itanium and HP aCC started using the IA-64
ABI.
Microsoft is the last remaining, relevant hold out.
There may be other compilers not producing the IA-64 C++ ABI. For example, I
have no clue what Green Hills' compiler produces, but since everything on
INTEGRITY is compiled into a single, statically-linked executable that runs in
kernel mode (it is your kernel), you must use the same compiler for
everything. And besides, if you're paying to use INTEGRITY, why would you not
use GHS' compiler?
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Platform & System Engineering
Received on 2024-07-18 15:17:16