Results from Intel´s C++ ABI Testsuite

Results from Intel´s C++ ABI Testsuite

[Andreas Jaeger]

I've downloaded Intel's C++ ABI Testsuite (available via
http://developer.intel.com/software/products/opensource/) and run it
with both GCC 3.1 CVS and GCC 3.2 CVS to check for ABI problems on
i686-linux-gnu.

I get with both GCC 3.1 and 3.2 the following error:

/opt/gcc/3.1-devel/bin/g++ -g -DSTDIO_OK -DUSE_FUNCTION_DESCRIPTORS -c -o operator1.o operator1.cpp
missing=0; \
for name in `./extract_mangled_names.sh "operator1.cpp"`; do \
  if ! nm operator1.o | grep ${name}'$' > /dev/null; then \
    echo '  missing:' "${name}" >&2; \
    missing=1; \
  fi; \
done; \
if [ ${missing} = 1 ]; then \
  exit 1; \
fi
  missing: _Znwm
  missing: _Znam
make[1]: *** [operator1.pass] Error 1


This means that these two names are mangled wrongly:
// ::operator new (size_t)
//% mangled name: _Znwm

// ::operator new[] (size_t)
//% mangled name: _Znam

nm has instead:
         U _Znaj
         U _Znwj

The difference here is unsigned int versus unsigned long as type of
the operator.  I don't know whether this is a real bug or a problem in
the testsuite but it doesn't look critical to me.

The good news is that this is the only problem that the ABI Testsuite
showed with GCC, all other tests passed!

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Results from Intel´s C++ ABI Testsuite

[Graham Stott]

Andreas Jaeger wrote:
[snip]
> This means that these two names are mangled wrongly:
> // ::operator new (size_t)
> //% mangled name: _Znwm
> 
> // ::operator new[] (size_t)
> //% mangled name: _Znam
> 
> nm has instead:
>          U _Znaj
>          U _Znwj
> 
> The difference here is unsigned int versus unsigned long as type of
> the operator.  I don't know whether this is a real bug or a problem in
> the testsuite but it doesn't look critical to me.
> 
size_t is either "unsigned int" or "unsigned long" could be that the
testsuite is assuming it's always "unsigned int".

> The good news is that this is the only problem that the ABI Testsuite
> showed with GCC, all other tests passed!
> 
> Andreas

Graham

Re: Results from Intel4s C++ ABI Testsuite

[Nathan Sidwell]

Andreas Jaeger wrote:

> I get with both GCC 3.1 and 3.2 the following error:

>   missing: _Znwm
>   missing: _Znam
> make[1]: *** [operator1.pass] Error 1

> nm has instead:
>          U _Znaj
>          U _Znwj
> 
> The difference here is unsigned int versus unsigned long as type of
> the operator.  I don't know whether this is a real bug or a problem in
> the testsuite but it doesn't look critical to me.
yes. I agree. this is operator new (size_t), the ABI does not
specify what type size_t should be, and 18.1/1 says size_t comes
from cstddef, which has the same contents as C header stddef.h, modulo
some changes. I don't have a C std in front of me, but IIRC size_t
is the first of 'unsigned int', 'unsigned long', 'unsigned long long'
that can hold an object's size. So, on an ILP32 machine, it will be
'unsigned int' and operator new (size_t) will be _Znwj. If
size_t is implementation defined, then we need to fix the ABI document
to specify the choice.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: Results from Intel4s C++ ABI Testsuite

[Richard Henderson]

On Sat, Jul 06, 2002 at 08:11:36PM +0100, Nathan Sidwell wrote:
> I don't have a C std in front of me, but IIRC size_t
> is the first of 'unsigned int', 'unsigned long', 'unsigned long long'
> that can hold an object's size. So, on an ILP32 machine, it will be
> 'unsigned int' and operator new (size_t) will be _Znwj.

Nope.  C standard only says it will be unsigned, nothing more.

About half of the ILP32 OSs use "unsigned int", and the other
half use "unsigned long".  You can do nothing but agree with
whatever the person who wrote the system headers decided.


r~

Re: Results from Intel4s C++ ABI Testsuite

[Joe Buck]

On Sat, Jul 06, 2002 at 08:11:36PM +0100, Nathan Sidwell wrote:
> > I don't have a C std in front of me, but IIRC size_t
> > is the first of 'unsigned int', 'unsigned long', 'unsigned long long'
> > that can hold an object's size. So, on an ILP32 machine, it will be
> > 'unsigned int' and operator new (size_t) will be _Znwj.

Richard H writes:
> Nope.  C standard only says it will be unsigned, nothing more.
> 
> About half of the ILP32 OSs use "unsigned int", and the other
> half use "unsigned long".  You can do nothing but agree with
> whatever the person who wrote the system headers decided.

It seems that for true C++ binary compatibility all implementers must
agree on the type of size_t.  Was this overlooked?

Re: Results from Intel4s C++ ABI Testsuite

[Gabriel Dos Reis]

Joe Buck <Joe.Buck@synopsys.com> writes:

| On Sat, Jul 06, 2002 at 08:11:36PM +0100, Nathan Sidwell wrote:
| > > I don't have a C std in front of me, but IIRC size_t
| > > is the first of 'unsigned int', 'unsigned long', 'unsigned long long'
| > > that can hold an object's size. So, on an ILP32 machine, it will be
| > > 'unsigned int' and operator new (size_t) will be _Znwj.
| 
| Richard H writes:
| > Nope.  C standard only says it will be unsigned, nothing more.
| > 
| > About half of the ILP32 OSs use "unsigned int", and the other
| > half use "unsigned long".  You can do nothing but agree with
| > whatever the person who wrote the system headers decided.
| 
| It seems that for true C++ binary compatibility all implementers must
| agree on the type of size_t.  Was this overlooked?

I can't say, that was overlooked.  I'd just say that is part of things
that are not portable across implementations, just like
std::string::size_type.

-- Gaby

Re: Results from Intel4s C++ ABI Testsuite

[Mark Mitchell]

> It seems that for true C++ binary compatibility all implementers must
> agree on the type of size_t.  Was this overlooked?

Sort of.

As Richard says, this is pretty much a property of the OS.  If "int" and
"long" are the same, you can interchange the two for binary compatibility
purposes, but you'll never make your header files work right.

And, of course, since "size_t" is just a typedef we can't mangle it
specially, even if we wanted to.

It is true that if my OS uses "long" and yours uses "int" -- but they
are the same in all other ways -- then I can't mix and match C++ shared
objects from our two systems.  I can still mix and match C++ shared
objects from any one of those systems, even if I used different
compilers to build them.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Results from Intel4s C++ ABI Testsuite

[Magnus Fromreide]

On Wed, 10 Jul 2002, Mark Mitchell wrote:

> > It seems that for true C++ binary compatibility all implementers must
> > agree on the type of size_t.  Was this overlooked?
>
> Sort of.
>
> As Richard says, this is pretty much a property of the OS.  If "int" and
> "long" are the same, you can interchange the two for binary compatibility
> purposes, but you'll never make your header files work right.
>
> And, of course, since "size_t" is just a typedef we can't mangle it
> specially, even if we wanted to.
>
> It is true that if my OS uses "long" and yours uses "int" -- but they
> are the same in all other ways -- then I can't mix and match C++ shared
> objects from our two systems.  I can still mix and match C++ shared
> objects from any one of those systems, even if I used different
> compilers to build them.

For me it sounds as if this would be a nice thing to put in a platform ABI
specification then. Is it in the IA-64 ABI spec that we are mostly using
for ix86 as well?

Re: Results from Intel4s C++ ABI Testsuite

[Richard Henderson]

On Thu, Jul 11, 2002 at 09:37:33AM +0200, Magnus Fromreide wrote:
> For me it sounds as if this would be a nice thing to put in a platform ABI
> specification then.

I think that's impractical.  One simply imports it from the
OS ABI specification.


r~

Re: Results from Intel4s C++ ABI Testsuite

[Richard Henderson]

On Sat, Jul 20, 2002 at 10:05:01AM +0100, Nick Ing-Simmons wrote:
> It seems to me (as a casual reader who does not use C++ much),
> that the fact that "type safe linkage" is encoding the "name" of the 
> type rather than the "type" is sub-optimal. If what was encoded
> was "unsigned integer of 32-bits" then the two size_t-s would match.

Unfurtunately, C++ allows a function to be overloaded based on
the type, and thus the mangling scheme must allow both f(int)
and f(long) to exist.  Which would not be possible if the mangling
were done based on width.


r~

Re: Results from Intel4s C++ ABI Testsuite

[Nick Ing-Simmons]

Mark Mitchell <mark@codesourcery.com> writes:
>> It seems that for true C++ binary compatibility all implementers must
>> agree on the type of size_t.  Was this overlooked?
>
>Sort of.
>
>As Richard says, this is pretty much a property of the OS.  If "int" and
>"long" are the same, you can interchange the two for binary compatibility
>purposes, but you'll never make your header files work right.
>
>And, of course, since "size_t" is just a typedef we can't mangle it
>specially, even if we wanted to.
>
>It is true that if my OS uses "long" and yours uses "int" -- but they
>are the same in all other ways -- then I can't mix and match C++ shared
>objects from our two systems.  I can still mix and match C++ shared
>objects from any one of those systems, even if I used different
>compilers to build them.

It seems to me (as a casual reader who does not use C++ much),
that the fact that "type safe linkage" is encoding the "name" of the 
type rather than the "type" is sub-optimal. If what was encoded
was "unsigned integer of 32-bits" then the two size_t-s would match.

The "loss" would be that programs that would work on that platform
- even though coded incorrectly - would link.
But catching long vs int confusion is better done before link time.

-- 
Nick Ing-Simmons
http://www.ni-s.u-net.com/

Re: Results from Intel4s C++ ABI Testsuite

[Joe Buck]

> On Sat, Jul 20, 2002 at 10:05:01AM +0100, Nick Ing-Simmons wrote:
> > It seems to me (as a casual reader who does not use C++ much),
> > that the fact that "type safe linkage" is encoding the "name" of the 
> > type rather than the "type" is sub-optimal. If what was encoded
> > was "unsigned integer of 32-bits" then the two size_t-s would match.
> 
> Unfurtunately, C++ allows a function to be overloaded based on
> the type, and thus the mangling scheme must allow both f(int)
> and f(long) to exist.  Which would not be possible if the mangling
> were done based on width.

The problem could have been avoided by going in the other direction and
making size_t a true type rather than a typedef in C++, and in fact, C++
did this with wchar_t.