incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: fails on AIX
Date Fri, 02 Nov 2007 19:42:58 GMT
Travis Vitek wrote:
> Farid Zaripov-2 wrote:
>>> From: Travis Vitek [] 
>>> The definition of the copy-ctor will come from somewhere else 
>>> [where?].
>>   The definition of the copy-ctor should be present in libc.
> The C library has definitions for C++ types that are supposed to be part of
> the C++ Standard Library? That just seems wrong. You must mean libC.a on AIX
> [or more generally the C++ library]. In that case I don't think any symbols
> should _ever_ come from there. We shouldn't be linking the C++ library at
> all if we can avoid it.
> None of this really explains why we don't always define all of the members
> of std::exception ourselves. I guess if we absolutely cannot avoid getting
> libC.a linked then we would see link errors complaining of multiply defined
> symbols, but I don't see them if I modify the config header and rebuild.

libC.a contains other important runtime symbols that C++ programs
can't do without (e.g., exception handling, runtime type id info,
dynamic memory management, etc.) We use the xlCcore command to avoid
linking with the native C++ Standard Library. IBM implemented xlCcore
partly in response to our complaints about problems due to mixing the
native and our implementation of the C++ Standard Library in the same
program. You can view the history of the whole issue here (on the
inside of the Rogue Wave firewall):

 From the issue you can see that we asked IBM to split up xlC.a into
two libraries like most other compiler vendors do: the C++ runtime
library and the rest of the C++ Standard Library. They decided to
do it their way and keep all symbols in the same library. I'm not
comfortable with the solution because it feels like magic to me and
makes me wonder if it even works, but unless we can point to actual
problems that it causes there's little we can do about it.


> Farid Zaripov-2 wrote:
>>> From: Travis Vitek [] 
>>> Anyways, an exception is created and copied out for the unwind. The
>>> exception is then copied back onto the stack at the location 
>>> the exception
>>> is handled. The code that actually copies the exception 
>>> expects the object
>>> to be 8 bytes in size, but the code that created the exception only
>>> allocates 4 bytes for it.
>>   The definitions of the std::exception class in STDCXX and AIX system
>> headers should be the same. If no, the include/exception header file
>> should have corresponding #ifdef _RWSTD_OS_AIX / #endif
> Technically that will break binary compatibility, right? I realize the
> STDCXX 'special' functions are all implemented as no-ops, but there is
> probably some contrived user-code that would break because of this change.
> If this change is indeed safe [I'm having trouble coming up with a testcase
> that will break because of it], then why don't we create a compiler test to
> determine if the exception class has has any pad so that we can pad out the
> declaration of std::exception. That way we would be able to conveniently
> avoid this problem in the future.
> Farid Zaripov-2 wrote:
>>> From: Travis Vitek [] 
>>> So here is my problem with all of this. How is this safe? If 
>>> the one of the 'special' functions provided by the system has
>>> some side effect, and we use that implementation, then how
>>> can we safely define any of the other 'special' functions?
>>> That said, what is the appropriate solution? Should we just 
>>> pad the type out to the correct size
>>   Yes, since the stdcxx uses std::exception class just as base class
>> for the other exception classes (the members of the std::exception are
>> not used).
>> Farid.
> I think the members of std::exception provided by stdcxx are actually being
> used when they are provided, but their definitions are 'dumb'.
> Travis

View raw message